W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2022

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

From: Wenbo Zhu <wenboz@google.com>
Date: Mon, 3 Oct 2022 11:20:49 -0700
Message-ID: <CAD3-0rNeUO2DF9Uhnj9fRCDZ2S94tiG=Mzp7WLAV14uQpp-ByQ@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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
>
Received on Monday, 3 October 2022 18:21:15 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 1 February 2023 02:18:31 UTC