: Considerations of the HTTP Content-MD5 Header We are debating whether to use the Content-MD5 header. Pros: The CMS allows us to easily include it with minimal overhead (cached responses in 80%+

@XinRu657

TCP already has error correction, but this only helps you on the TCP layer. An intermediary HTTP proxy or load balancer can corrupt the data on the HTTP layer, and then retransmit it. A HTTP MD5 makes it possible to detect this corruption. The reason why nobody really talks about this need is that the problem is very rare indeed; most HTTP proxies etc "just work".

The RFCs allude to security. IMHO this is so weak it should be ignored -- if you need any kind of real security and confidentiality, then you need HTTPS.


Do certain media types include their own form of digest that makes this unnecessary?


Not anything really good. But a few bit errors in photos, streaming video etc will often be imperceptible to humans.

I would say it depends on the use case:


For REST based web services a digest adds a useful layer of additional error correction. See this AWS failure as an example.
For applications dealing with mission-critical data over plain HTTP it is worth implementing. Content-MD5 gives clients the option to verify the end-to-end transmission integrity.
For 'normal' web sites serving up text and media of 'normal' value the Content-MD5 header serves no purpose. And I honestly don't even know how many mainstream browsers (PC, especially mobile) actually support it.

Vote Up Vote Down

@Angela700

MD5 checks add latency to web page load times.


If true (and the latency is not entirely trivial) then I'd say it wasn't worth it.

In general, I believe, the last modified header is most commonly used to determine if a page has changed. Assuming you provide meaningful value there, I see no need for the content-md5 header.

Vote Up Vote Down