Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Sometimes we are facing a problem with corrupted files after upload through HTTP protocol.

Today I’ve read an article that says that TCP protocol is not 100% reliable due to weak CRC algorithm and other different things.

As I understood from RFC, HTTPS uses TLS over TCP and uses hash functions while processing. I.e. data integrity is additionally controlled.

Can I consider upload to be 100% reliable (or how much more reliable?) if I just switch the protocol to HTTPS?

share|improve this question
up vote 3 down vote accepted

While TCP (the protocol on which http/https is built) has error-detection in the form of a checksum on board (which triggers retransmissions), it's not bulletproof. It is very rare, but numerous bit flips in the same packet could still result in a valid checksum. If the rest of the packet is still undamaged, those errors could travel all the way into your application. I'm conveniently skipping over error detection/correction in lower layers of the transfer here.

Generally, encryption algorithms include much stronger checksums, as part of the data security. TLS/SSL (over TCP) certainly does, so you conclusion is technically valid.

However, do note that this is very, very rare; on the same scale as errors in (non-ECC) ram, sata cables and disk storage (both on server and client side!). For reliability purposes, to switch to https without targetting those other potential problems is silly and will never achieve "100%" reliability.

In my experience, it's just as likely the cause is with some other part of the system (application processing the uploaded data, maybe silent format conversion in the database, ...).

This whole problem applies to non-http protocols too.

share|improve this answer

BTW - The article you cite is over 11 years old.

I've never heard of HTTPS being more reliable than HTTP (and not heard of HTTP being unreliable even) - so I wouldn't think it will make a difference. However I may be wrong.

Bit what I would say, is that before you start pointing the finger at the protocol, are you absolutely sure your upload procedure or application isn't causing the problem? For instance I've come across surprising download/upload issues in PHP before, which were confusing but easy to fix in the end.

You also don't mention actually what you uploading, it's size, and level of corruption that is occurring.

share|improve this answer
Thx for answer. The article is old but HTTP is even older… The question has more theoretical meaning. We are developing upload software and sometimes our clients complain about corrupted data arriving in rare cases. I’m not saying that client/server code is always perfect, but for now my interest is protocol. – Eugene Mar 4 '11 at 8:24
@Eugene, if you are developing an application and have concerns about reliable transmission you need to perform integrity checks at the application level, not rely on low level checks that are of necessity fairly minimal. – John Gardeniers Mar 4 '11 at 11:40
In most cases my app is used to upload not very important data. The best thing I can do about controlling integrity is sending some hash code within upload data. As I understand, the TLS protocol does the same thing but in lower level. Besides, additional checksum verification will give more loads for server. – Eugene Mar 4 '11 at 11:57

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.