Re: Transfer-codings, mandatory content-coding support and intermediaries

On 21 April 2014 22:22, <K.Morgan@iaea.org> wrote:

>
> Regarding my suggestion below, will somebody please at least respond and
> tell me why I'm wrong and/or give another suggestion?
>
> On 19 April 2014 21:54, MORGAN, Keith Shearl wrote:
> > I suggest something like the following...
> >
> > Intermediaries MUST NOT add GZIP compression to a DATA frame.
> Intermediaries MAY
> > remove GZIP compression frome DATA frames if necessary. Intermediaries
> MAY also
> > remove and re-apply GZIP compression, so long as all compressed data were
> > originally compressed by the origin.
> >
> > For example, an intermediary might elect to remove GZIP compression for
> local
> > storage in its cache in order to more easily extract a range from the
> content. In
> > this case, when serving a range, the intermediary can choose to send the
> range in
> > DATA frames with no compression or with GZIP compression (or a
> combination
> > thereof).
>
>
It's too hard to enforce that MUST NOT; it's quite likely to become an RFC
6916-style "MUST NOT (BUT WE KNOW YOU WILL)"​. Or put more politely: if
someone implemented it by mistake, how would anyone ever detect it?

An alternative which I'm starting to imagine might be to use END_SEGMENT to
delineate secret data and potentially-attacker-supplied data; that way we
can ensure that the two sets of data never end up in the same DATA frame /
compression context. That resolves the vulnerability I'm aware of
introduced by compression; I don't know how to protect against
vulnerabilities of which I'm not aware, in anything.


-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/