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