[Bug 11895] Make Downloads more reliable by specifying checksums

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11895

--- Comment #5 from Andrew Roth <andrew.in.snow+w3c@gmail.com> 2011-01-28 22:12:44 UTC ---
> Content-MD5 doesn't help you if the incorrect file was uploaded, or if it was
> corrupted on disk.  Also, it's harder to configure.

Unfortunately, nothing will help if you (I presume the publisher) upload the
wrong file.  This proposed solution will only make all downloads show up as
failed.

Content-MD5 is, however, much more difficult (from the designer/publisher
perspective) to configure and use.

> > This places a burden on the server because it has to compute the checksum upon
> > every request.
> 
> Or just store it on the server and put it in the header, right?

Ref: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.15

According to the spec, it states:
"Only origin servers or clients MAY generate the Content-MD5 header field"

Ref: http://httpd.apache.org/docs/2.2/mod/core.html#contentdigest

Apache's httpd documentation states that the message digest is calculated upon
each request, placing a burden on the web server.  In fact, they seem to
recommend *against* using this feature by saying:
"Note that this can cause performance problems on your server since the message
digest is computed on every request (the values are not cached)."

I want to stress the negative associated with generating the hash upon each
request.  For files where this would be useful (very large files) the checksum
would take a great deal of compute power to calculate (compared to not
calculating, and simply serving the file).  This is normally not expected of
web servers, especially shared hosting.

Yes, I understand that by using some scripting magic, one can use PHP or CGI to
send stored hash values in the header prior to sending the actual file.  This
increases the complexity and difficulty of implementation, which is simply not
ideal.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 28 January 2011 22:12:46 UTC