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