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

Re: C-E for clients, was: Support for gzip at the server #424 (Consensus Call)

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Tue, 13 May 2014 10:21:41 +1000
Message-ID: <CACweHND3-HTZE0PzxO_6G2C=u=eH3d5vTCpeS-ZKju-9UdvUAg@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>, Roy Fielding <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 12 May 2014 18:18, Julian Reschke <julian.reschke@gmx.de> wrote:

> On 2014-05-12 09:38, Matthew Kerwin wrote:
>>     Maybe. But it really doesn't matter what the server "stores", what's
>>     relevant is what it returns on GET.
>>     What particular metadata are you concerned with?
>> I used "store" as a short hand for "provide a subsequent representation
>> based on what was received". I don't overly care if the file is
>> compressed or not in their data store.
> I would expect the server to return the gzipped content upon GET (with C:E
> gzip) unless it determines that the client doesn't support gzip.
​I think that ​underpins my confusion. Thinking a bit more clearly, I see
that if I PUT a c-e:gzip resource, I can GET that c-e:gzip resource, and if
I don't accept the gzip encoding the server is free to do whatever it
likes, including 406. I had a much more convoluted and overcomplicated
state diagram in my head.

>  Regarding metadata, originally I had in mind properties like
>> Last-Modified time. I may not be thinking clearly about it at the
>> moment, I blame my cold. I also think I need to look into what people
>> currently do when a PUT contains Last-Modified.​
> I believe most servers ignore it, but if they don't, I would expect them
> to apply it internally consistently.
> Doesn't the same question apply anyway? What is L-M if the server gzips on
> the fly?
As long as you can guarantee that the de/compression routines produce
identical bytes on subsequent invocations, the two (or more)
representations can share last-modified (but not ETag).

Hmm.. ​That pretty concisely addresses my concern.

>> As a user of HTTP I am currently able to serve a resource using three
>> equivalent (to a greater or lesser degree) representations:
>> * foo.html (c-t:text/html)
>> * foo.html.gz (c-t:text/html, c-e:gzip)
>> * foo.html.gz (c-t:application/gzip)
>> For my own convenience, I've statically generated two files, and use
>> some business logic and configuration to determine which file I use to
>> service each request, with what headers. But I can only do all this if
>> I'm on the server side.
> Ok. I can see why you'd want that when serving large files (tar.gz etc),
> but why for HTML?
​The Google told me to! <

But seriously, it might be a bad example, but​ for any resource I serve I
want to choose between raw, content-encoded, or gzipped. I may make
consistent choices for a single resource, but the same decision logic can
apply to all resources.

​Your tarball example​ opened up a whole new set of questions in my head,
mostly about encoding-specific resources and representations. I'll go think
about it somewhere else, though.

 ​I'd also like to be able to upload files, and depending on what files I
>> have on my workstation​ PC, I'd like the option to:
>> * upload foo.html, updating the existing foo.html
>> * upload a pre-zipped foo.html.gz and have it deflated by the server,
>> updating foo.html
>> * upload foo.html.gz, updating the existing foo.html.gz
>> ​[...]

> Understood.
> I believe this is a browser issue, not a protocol issue.
Yeah ​I think that's true. I'll stop complaining.​ :)

>  An alternative solution is to use different PUT/POST resources (e.g.
>> using query parameters to tell the server whether I want to unzip or
>> not), or extra parameters in the POST, or something to that effect.
>> However that's just moving the C-E negotiation out of the protocol, into
>> the application; so why bother specifying it here in the first place? If
>> it's just for the dynamic compress case, well, HTTP/2 already has a
>> setting/flag to allow dynamic compression in either direction. *hint hint*
> That's fine, but it doesn't help with 1.1.
​This goes directly to Mark's question: if it's available to 1.1, will any
1.1 implementers actually use it? I see it as a pretty niche concern, but
then I don't have the same overview of the internet as others on the list

That said, I think my concerns were unwarranted or have been addressed.
Sorry for the noise.

  Matthew Kerwin
Received on Tuesday, 13 May 2014 00:22:09 UTC

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