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

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?

> ... Remember, CE is a property of the representation, not a “transparent” encoding like TE.

But that doesn't mean the server can't do whatever it wants with it.

> That said, the resource is free to have side effects attached to a PUT — e.g. decompressing something.

Right.

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

> The PUT response type and headers, and the interface that allows the PUT.
>
>> * Also: how does it play with RFC 1867/2388? At a glance I'd imagine that any content-encoding is decoded before the multipart/form-data is parsed; are there any emergent issues with that?
>
> Don’t think so...

Correct.

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

Best regards, Julian

Received on Monday, 12 May 2014 06:24:57 UTC