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: Willy Tarreau <w@1wt.eu>
Date: Tue, 29 Apr 2014 08:33:04 +0200
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Matthew Kerwin <matthew@kerwin.net.au>, Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <20140429063304.GA1593@1wt.eu>
On Mon, Apr 28, 2014 at 01:22:33PM +0200, Julian Reschke wrote:
> On 2014-04-28 12:45, Matthew Kerwin wrote:
> >...
> >???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
> 
> HEAD? PROPFIND? AtomPub?
> 
> >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.
> >...
> 
> Yes, many ways to do that. But there should be a single way, so that 
> middleware can do it automatically.

In HTTP/1.1, we have 100-continue which would be the perfect fit for this.
The client waits for the server's agreement to send contents, and the
server could advertise its supported compression algorithms (both T-E and
C-E) in the 100-continue. And the benefit is that if an intermediary needs
to scan this content, it sends the 100 itself and will advertise what it
supports.

I don't know how we could translate that into 2.0 though.

Willy
Received on Tuesday, 29 April 2014 06:33:35 UTC

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