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: Matthew Kerwin <matthew@kerwin.net.au>
Date: Mon, 28 Apr 2014 20:45:29 +1000
Message-ID: <CACweHNCBa2gYeG6giPAu9FdshHYdBtxPK6HTy7yni52po7bF-Q@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 28 April 2014 20:17, Julian Reschke <julian.reschke@gmx.de> wrote:

> On 2014-04-28 12:09, Matthew Kerwin wrote:
>
>> On 28 April 2014 19:58, Julian Reschke <julian.reschke@gmx.de
>> <mailto:julian.reschke@gmx.de>>wrote:
>>
>> ​​
>>
>>     On 2014-04-28 11:48, Mark Nottingham wrote:
>>
>>         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.
>>         ...
>>
>>
>>     In HTML?
>>
>>
>>
>> ​<form action="/rsrc-that-accepts-gzip" method="POST"><input type="file"
>> name="f"></form>
>> ​<p>Select a file to upload (gzip files will be automatically
>> extracted)</p>
>>
>
> How does this help when my client is not a browser?
>
> Best regards, Julian
>
>
​How does your non-browser client discover that the resource exists in the
first place, or can be POSTed or PUT to? That's the place to add that it
​can handle zipped files. Whether that be in the linking hypermedia, or
offline API documentation, or a new link extension in a Link header, etc.

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/
Received on Monday, 28 April 2014 10:45:56 UTC

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