Re: [integrity] What should we hash?

The HTTPbis docs are going to obsolete RFC2616 in a few weeks, so it's best to look at them.

I think you want to say that integrity operates upon the payload of the message - see
  http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-26#section-3.3

This is after chunk encoding, gzip transfer-codings, etc. have been removed. However, content-codings are still there, e.g., for gzip, deflate in the Content-Encoding header.

That's because Content-Encoding is considered a property of the representation in HTTP, even though many people implement it as a separate layer.

If you want to do it before content-encoding, you'd need to specify it explicitly; e.g., as "the message payload before content codings are applied."

Hope this helps,

On 12 Mar 2014, at 3:58 am, Devdatta Akhawe <dev.akhawe@gmail.com> wrote:

> Hi
> 
> One key question for integrity spec is "What should the browser hash?"
> Boris mentioned this previously
> http://lists.w3.org/Archives/Public/public-webappsec/2013Dec/0048.html
> 
> Informally, I am leaning towards hashing content after undoing stuff
> like gzip, deflate, chunked-encodings etc. Does that sound reasonable?
> 
> Next, how do we formalize (spec) this? In an ideal world, just saying
> "undo transfer-encoding" would be enough (i.e., spec would say "hash
> entity body"). But, common behavior is to apply gzip via
> Content-Encoding not transfer-encoding. And we want to hash after
> undoing gzip. (see Boris' email above)
> 
> Mark: Do you know good specification text for this? After looking at
> the HTTP RFC, one wording that springs to my mind is: ""After decoding
> the entity to the media-type referenced by the content-type header"
> 
> Thanks
> Dev

--
Mark Nottingham   http://www.mnot.net/

Received on Thursday, 13 March 2014 00:48:25 UTC