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

On Tue, Nov 1, 2022 at 9:22 PM <squid3@treenet.co.nz> wrote:

> On 2022-11-02 14:19, Wenbo Zhu wrote:
> > No. The server has rules that decide what MIMI types are compressible.
> > It
> > is possible for a client to apply C-E against an incompressible mime
> > type
> > (as decided by the server).
>
> This is backwards. CICE is for clients to make compression decisions,
> not the server. All the server can do is inform the client which
> decoders it has implemented.
>
>
> > With 415, the server may have to honor the client's decision to
> > indicate AE
> > for the request, when the server will not compress the response of the
> > same
> > CT.
>
> That certainly sounds like a server bug to me. The server advertised
> that it can receive gzip.
> It should either employ the gzip decoder it told the client it has
> access to, or only advertise identity encoding in the first 415.
>

The question is not about responses.

There are two options for the A-E value

A-E: gzip  (when the server knows that it is wrong for the client to
compress the request C-T)
A-E: identity (when the client intends to compress the request body)

The detailed rules known to the server to decide what C-Ts are compressible
may not be known to the client (http lib).


> CICE has nothing to do with response content, nor what the server would
> do when sending any C-T.
>
>
> AYJ
>
> >
> > Thanks,
> > Wenbo
> >
> > On Thu, Oct 13, 2022 at 2:22 AM Julian Reschke <julian.reschke@gmx.de>
> > wrote:
> >
> >> Am 03.10.2022 um 20:20 schrieb Wenbo Zhu:
> >> > 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".
> >>
> >> But that's a server bug, no?
> >>
> >> Best regards, Julian
> >>
> >>
>
>