W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Support for gzip at the server #424 (Consensus Call)

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 28 Apr 2014 19:48:15 +1000
Cc: ietf-http-wg@w3.org
Message-Id: <7A9F9F1E-FF74-4DDB-AEC4-FACF834D7781@mnot.net>
To: "Julian F. Reschke" <julian.reschke@gmx.de>
Iím saying that the most concrete way of encouraging servers to accept content-encoded request representations is to give them a means of declaring their support for doing so ó e.g., in HTML ó not a generic SHOULD in a place that resource authors will never look. 


On 28 Apr 2014, at 7:44 pm, Julian Reschke <julian.reschke@gmx.de> wrote:

> On 2014-04-28 08:53, Mark Nottingham wrote:
>> 
>> On 27 Apr 2014, at 2:03 am, Julian Reschke <julian.reschke@gmx.de> wrote:
>> 
>>> Not convinced.
>>> 
>>> If it's a characteristic of the representation, why can't the client sending the representation decide on it?
>> 
>> Because that would be a unilateral decision, just like the client deciding that itís going to send application/foobar+baz to your resource.
> 
> I don't understand the comparison.
> 
> A client can send any payload type it wants. The server can reject it if it doesn't understand it. This applies both to media types an content encodings.
> 
> What I'm looking for is to *encourage* servers to understand C-E gzip.
> 
> (And yes, the compression changes might address my use case, but I haven't looked into those yet)
> 
> > ...
> 
> Best regards, Julian

--
Mark Nottingham   http://www.mnot.net/
Received on Monday, 28 April 2014 09:48:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC