RE: #445: Transfer-Codings

On 23 April 2014 22:37, Martin Thomson wrote:
>
> I've included the changes [1].  Again with changes:
>
> There are security considerations now.
> There is a note about Content-Length.
>
> https://github.com/http2/http2-spec/commit/a02f5a868d99234cc19c7644ad38f91e151413fb

Some comments regarding the security considerations...


> Intermediaries MUST NOT alter the compression of <x:ref>DATA</x:ref> frames unless additional information is available that allows the intermediary to identify the source of data.



I was under the impression that you and Matthew said this couldn't be a "MUST NOT" requirement because it's not enforceable.  Perhaps I misunderstood.





> In particular, frames that are not compressed cannot be compressed, and frames that are separately compressed cannot be merged into a single frame.



Why is merging disallowed? Two (or more) gzip files can be concatenated to form a single gzip. So unless there is a security issue I'm missing, I don't see why this is a problem.





> Compressed frames MAY be decompressed or split into multiple frames.



Do you mean split after decompressing? That's ok.  The way I read the sentence, though, is that you can split compressed frames into multiple frames.  You can't do that because each frame has its own gzip context and the second, etc. frames (and possibly even the first) would not be decompressable after a split.





Finally, what about removing and then re-applying gzip (e.g. to extract a range).  That should be ok too.



This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Wednesday, 23 April 2014 21:23:40 UTC