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

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?

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

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

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.


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/