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: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 7 Nov 2022 20:55:19 +0100
Message-ID: <3b476ba5-04b0-79d5-8e41-bef5b82ec70b@gmx.de>
To: Wenbo Zhu <wenboz@google.com>
Cc: ietf-http-wg@w3.org
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
Received on Monday, 7 November 2022 19:55:38 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 28 January 2023 21:29:46 UTC