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

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.

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

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

Ok. I can see why you'd want that when serving large files (tar.gz etc), 
but why for HTML?

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

I don't believe you'd be violating PUT semantics here.

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

Understood.

I believe this is a browser issue, not a protocol issue.

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

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

(to Mark: there's really little to implement here in practice (for 
gzip). Servers that already allow C-E:gzip essentially don't need a 
change at all; servers that do not would switch to from status 400 to 
415 (httpbis already says so) and add "Accept-Encoding: identity". Seems 
I should a deployment considerations chapter :-)

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


Best regards, Julian

Received on Monday, 12 May 2014 08:19:12 UTC