Subject: FW: Content-* Semantics [i103]

From: "Brian Smith" <[email-masked]>
Date: Thu, 28 Feb 2008 16:14:06 -0800

Frank Ellermann wrote:
> Brian Smith wrote:
>  
> > headers like Content-MD5 (recalculate MD5 if you
> encode/decode using
> > Content-Encoding)
> [...]
> > need special processing when you "regurgitate" them.
> 
> What "special processing" apart from what is stated in RFC
> 1864 do you have in mind ?
> 
> | To generate the value of the Content-MD5 field, the MD5
> algorithm is
> | computed on the canonical form of the MIME entity's object.  In 
> | particular, this means that the sender applies the MD5 algorithm on 
> | the data immediately after conversion to canonical form, before 
> | applying any content-transfer-encoding, and that the receiver also 
> | applies the MD5 algorithm on the canonical form, after undoing any 
> | content-transfer-encoding.

There is no content-transfer-encoding in HTTP, and
Content-MD5/Content-Encoding processing works exactly the opposite way:
if the request is compressed, you need to calculate the MD5 on the
compressed request; if you later serve the uncompressed variant, then
you need to recalculate the Content-MD5 or remove it. That is the
"special processing" that I was referring to.

- Brian

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 29 Feb 2008 02:15:48 +0100

Brian Smith wrote:
 
> There is no content-transfer-encoding in HTTP

Yes, I confused CTE and TE, again.  Some years ago all
I wanted to know was how I can disable chunking, that
turned out to be simple, use "GET whatever HTTP/1.0".

> Content-MD5/Content-Encoding processing works exactly

| The MD5 digest is computed based on the content of
| the entity-body, including any content-coding that
| has been applied, but not including any transfer-
| encoding applied to the message-body.

Okay, so for some chunked gzipped content the MD5 is
apparently for the gzipped content.  I also read #40,
if you want to update all RFC 4229 registrations the
IANA considerations could get very impressive, maybe
a bulk update will do, let IANA replace 4229 by 2616bis
for <huge list of header fields defined in 2616bis>.

 Frank