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

On 12 May 2014 16:24, Julian Reschke <julian.reschke@gmx.de> wrote:

> On 2014-05-12 05:14, Mark Nottingham wrote:
>
>>
>> On 12 May 2014, at 1:05 pm, Matthew Kerwin <matthew@kerwin.net.au> wrote:
>>
>>  Technically this looks good to me (a little better after mnot's tweaks).
>>>
>>> I'm left wondering:
>>>
>>> * What does it mean for a server to receive an encoded payload? E.g. if
>>> I PUT a gzipped file, should the server store the gzip file? And/or should
>>> it use it to generate/overwrite an unzipped copy? And if so, what metadata
>>> does the unzipped copy get?
>>>
>>
>> You’d store the gzip’d representation, with a vanilla PUTtable resource.
>> ...
>>
>
> 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.

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



>
>
 * How does one convey that^ decision, and other options, to the user? I'm
>>> imagining a file upload dialog that says either "Any file you upload
>>> (including a gzip file) will be stored as-is", or "If you upload a gzip
>>> file it may be unzipped at the server before being processed" with a
>>> checkbox to allow the user to instruct the UA to send it as
>>> Content-Type:application/gzip rather than Content-Encoding:gzip. I know
>>> this was not intended to be used in browsers, but ... <dramatic ellipsis>.
>>>
>>
> My understanding is that you don't convey it at all. Could you explain
> what use case you're thinking of?
>
>
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.

​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

​(I imagine I'd have set up my server to accept a POST to the directory
resource, so we don't have to worry about violating the semantics of PUT.)

​For the first option, the browser can do dynamic compression. I'd argue
T-E is better here, but pragmatically if the data gets through fine, I'm
happy with whatever works.​

For the second and third options I'd choose the same file in the
file-picker, but I'd want the browser to send it with either
c-t:text/html+c-e:gzip, or c-t:application/gzip, based on ​the client-side
equivalent of my business logic and configuration. The problem is, being a
browser, it would have to use UI elements to allow me to specify which I
want.

In the current world I only have the first and third options, because they
don't use content encoding on the request; so effectively I'm after some UI
element that allows me to tell the browser that what I'm uploading uses
C-E. The same sort of static C-E I currently use today on my server.

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*



>  As a completionist I like that this proposal fills in a gap, and I think
>>> there is value in having it specified, but overall it feels like we might
>>> be packing yet more transport compression into entity encoding, rather than
>>> addressing the existing mess.
>>>
>>
>> Well, the real question is whether anyone will implement it, surely?
>>
>
> I'm all for making T-E work in practice, but that shouldn't stop us from
> improving C-E.
>
> This change is so tiny what it really should have been in HTTPbis. We just
> were too late thinking about it.
>
>
​Yeah, I'd thought in the past that it was a little hole just waiting to be
specced in​, but I never had enough of a reason to use it for me to
complain about it.



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