Re: #445: Transfer-Codings

On 23 April 2014 14:21,  <K.Morgan@iaea.org> wrote:
> > 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.

Perhaps you did.  Security considerations don't tend to include
requirements that are enforceable in the classic sense.  If an
intermediary compresses despite being ignorant about what it's
compressing, then the violation might be hard to detect for a client.
But it can create a security vulnerability.  That has a different sort
of enforcement associated with it.

>> 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.

As long as the compression context is shared for the merged fragments,
then it is OK I suppose.  The concern here is that an origin server
might split frames intentionally in order to make it clear to
downstream consumers that the content of those frames cannot be mixed
in the same compression context.  Having an intermediary undo that
would be bad.

>> 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.

Indeed, I thought that much was obvious, but on a re-read, I think a
few extra words might be needed here.

Received on Wednesday, 23 April 2014 21:43:56 UTC