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

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.

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

Received on Wednesday, 2 November 2022 04:19:14 UTC