- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Wed, 12 Mar 2014 22:37:42 -0700
- To: Mark Nottingham <mnot@mnot.net>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Boris Zbarsky <bzbarsky@mit.edu>
Thanks! Does "representation" or "the message payload before content codings are applied." sound right to others? Boris? I (or one of the editors) will update the spec soon unless someone flags an issue. ~Dev On 12 March 2014 22:28, Mark Nottingham <mnot@mnot.net> wrote: > That would be the representation - see: > http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-3.1.1.5 > > You should still probably have a few words around it to clarify; this sort of thing is easy to mess up. > > Cheers, > > > On 13 Mar 2014, at 4:24 pm, Devdatta Akhawe <dev.akhawe@gmail.com> wrote: > >> Thanks! Intuitively, it seems there should be a simpler way to refer >> to "the message payload before content codings are applied.". >> >> What does the content-type refer to? Type of what? For example, if I >> am not completely wrong, content-type of a text file with gzip >> content-encoding is still text/plain and so presumably talks about >> "before content codings are applied" >> >> thanks >> Dev >> >> On 12 March 2014 17:47, Mark Nottingham <mnot@mnot.net> wrote: >>> 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/ >>> >>> >>> > > -- > Mark Nottingham http://www.mnot.net/ > > >
Received on Thursday, 13 March 2014 05:38:28 UTC