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

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! <
https://developers.google.com/speed/docs/insights/EnableCompression>​

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
do.​

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


-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/