Re: Deployment of draft-ietf-httpbis-cice (Client-Initiated Content-Encoding)

We ran into a corner case in responding 415 to a br-compressed request on a
server which hasn't enabled br support.

When the client chooses to compress (br) an incompressible mime type (as
the server decides), the server will advise "A-E: gzip" instead of "A-E:
identity".





On Sun, Jun 25, 2017 at 3:47 AM Julian Reschke <julian.reschke@gmx.de>
wrote:

> On 2017-06-16 23:33, Wenbo Zhu wrote:
> > <https://tools.ietf.org/html/draft-ietf-httpbis-cice>
>
> Actually: RFC 7694 (https://www.greenbytes.de/tech/webdav/rfc7694.html)
>
> > I am planning to start to advise A-E with 415 responses.
>
> Awesome!
>
> > Questions to the working group:
> >
> > 1. Does CICE alone address the concern to support/enable request
> > compression in U-A?
>
> That was the intent of the spec.
>
> > 2. I suspect the success rate of non-negotiated use of (gzip) request
> > compression will be very high over Internet, esp. if the server
> > end-point is managed by the content author. Any suggestion otherwise?
>
> We've been using gzip-encoded request bodies for ages in WebDAV - just
> not in browsers.
>
> > 3. Any known deployment of gzip/brotli compression in browsers?
>
> Might be of interest:
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1221461> (cc: Patrick :-).
>
> Best regards, Julian
>