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

On 07.11.2022 19:56, Wenbo Zhu wrote:
>
>
> On Wed, Nov 2, 2022 at 11:37 AM Julian Reschke <julian.reschke@gmx.de
> <mailto:julian.reschke@gmx.de>> wrote:
>
>     On 02.11.2022 18:45, Wenbo Zhu wrote:
>      > ...
>
>     I still don't get what the issue is.
>
>     Could you post a complete message exchange that illustrates the
>     potential problem?
>
> Client sends a POST with C-T: Foo; C-E: br
> Server doesn't yet support br uncompression, and will now return 415
> (based on this spec), instead of something like 400
> Server also needs to set A-E: gzip. However, based on the rules known to
> the server, Foo is not a compressible (with gzip at least) media type

I don't get what you mean by "is not compressible". gzip can be applied
to any content type. Yes, that might not be a good choice when the media
type already is inherently compressed, but that's up to the client to
decide, no?

> The question is whether A-E: identity is preferred.

That would signal that the server doesn't want C-E-compressed payloads.
You can do that.

So it seems that the server *in principle* supports payload compression
in request payloads, but want's to refuse uncompression for certain
media types. Why?

Best regards, Julian