Re: Support for gzip at the server #424 (Consensus Call)

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. Remember, CE is a property of the representation, not a “transparent” encoding like TE. 

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

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

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

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

Cheers,


> 
> 
> On 12 May 2014 12:03, Mark Nottingham <mnot@mnot.net> wrote:
> LGTM. I’d tweak these to paragraphs:
> 
> >    This specification extends that definition to allow "Accept-Encoding"
> >    as response header field as well.  When present, it indicates what
> >    content codings a server is willing to accept in requests.  In
> >    particular, a field value that contains "identity" only implies that
> >    no content codings are supported at all.
> >
> >    Note that this information applies to the resource to which the
> >    request was addressed.  The set of supported encodings might vary for
> >    different resources on the same server, and could also vary depending
> >    on other aspects of the request (such as the request method).
> 
> to:
> 
> “””
> This specification extends that definition to allow "Accept-Encoding"
> as a response header field as well.  When present, it indicates what
> content codings a resource is willing to accept in future requests.
> A field value that only contains "identity" implies that no
> content codings are supported.
> 
> Note that this information is specific to the requested resource.  The
> set of supported encodings might be different for resources on the
> same server, and could also change depending on other aspects of the
> request (such as the request method).
> “””
> 
> Cheers,
> 
> 
> -- 
>   Matthew Kerwin
>   http://matthew.kerwin.net.au/

--
Mark Nottingham   http://www.mnot.net/

Received on Monday, 12 May 2014 03:15:32 UTC