14.15 Content-MD5
The Content-MD5 entity-header field, as defined in RFC 1864 [23], is an MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body. (Note: a MIC is good for detecting accidental modification of the entity-body in transit, but is not proof against malicious attacks.)
HTTP/1.1: Header Field Definitions
ATM Lucee completely ignores this header, but we could integrate this into the language in various ways.
Server part
we could add a new attribute to the tag cfcontent with name “hash” (suggestions for a better name?) that when trues adds the “Content-MD5” header to the response, we could also have an admin setting for this to define the default behaviour and inside the application.cfc you always can do
this.tag.content.hash=true;
Client part
the http file resource and the tag cfhttp could detect this header and check the result and throw an exception when the result is invalid. again we could have a attribute for the tag cfhttp to control this.
3 Likes
I like it; variable name is a little tricky though. Perhaps:
content addContentHash=true;
http url=urlToGet method="get" validateContentHash=true;
You might also need to be able to tell Lucee to add hashes to all requests without ever using cfcontent
I’m unclear as to how many sites actually send this header, let alone how many clients verify it.
Based on here: https://bugzilla.mozilla.org/show_bug.cgi?id=232030
Mozilla doesn’t support it
And based on their references in the last 2 or 3 posts of the thread, it has been superseded by Content-Digest. (Which I’m betting few sites use either)
It’s probably simple to implement, although it requires some trickery - because you’ll either need to buffer the entire stream or be able to rewind/reopen it - which means for things like cfcontent - you’ll have to buffer the entire generatedContent before sending any of it. (Since the headers need to be transmitted first)
On the client side we won’t have that problem, since CF is consuming the stream (and closing it) anyway, so it’s already in memory and already fully read. But it’s also relatively simple for a developer to generate a MD5 hash and compare it against a returned header if they have a case to do so (and a site that supports it)
Is there currently a use case where this validation is necessary, specifically this header (vs Content-Digest)? If there is, any reason you wouldn’t implement both? And if so, the design of the variables and tags should be structured to support both.
As an aside, what about incoming/outgoing requests from Lucee+Tomcat proper? Does Lucee currently send this header? (or verify it)
I don’t believe Tomcat sends or validates this header in its current form.
It also appears nginx does not support this header.
Apache appears to conditionally support it:
“Content-MD5 is only sent for documents served by the core, and not by any module. For example, SSI documents, output from CGI scripts, and byte range responses do not have this header.”
1 Like