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

From: Mark Nottingham <[email-masked]>
Date: Fri, 25 Apr 2014 10:30:42 +1000

Re-visiting this; I still think we can close #424 with no action. Any disagreement?

Regards,

On 25 Mar 2014, at 10:36 am, Mark Nottingham <[email-masked]> wrote:

> 
> On 21 Mar 2014, at 6:01 pm, Julian Reschke <[email-masked]> wrote:
> 
>>>>> I don't think anyone is talking about *limiting* what you can do in HTTP/2 here -- what's being discussed is whether server-side support for GZIP content-coding in requests should be *required*.
>>>> 
>>>> I think it would be good if we (a) encouraged servers to do it, and (b) clarified error handling if you don't.
>>>> 
>>>> 1) Define a status code for "unsupported content-encoding" (plus maybe discovery via a Accept-Encoding header field that can be sent with it)
>>> 
>>> Right now this falls into 415 Unsupported Media Type:
>>> 
>>> """
>>>   The 415 (Unsupported Media Type) status code indicates that the
>>>   origin server is refusing to service the request because the payload
>>>   is in a format not supported by this method on the target resource.
>>>   The format problem might be due to the request's indicated Content-
>>>   Type or Content-Encoding, or as a result of inspecting the data
>>>   directly.
>>> """
>>> 
>>> So, it could be a new status code (that takes "or Content-Encoding" out of the definition of 415), or it could be a header on 415 that further refines its semantics.
>> 
>> Ah. I had forgotten that we added this to the description of 415.
>> 
>> So if we want to go down that route, we could recommend a 415 and in addition elevate "Accept-Encoding" to a response header field that could be used with 415.
> 
> That seems to make sense, but it isn't something specific to HTTP/2, and it's extending the semantics of a HTTP/1 header field. That sounds like a new spec that updates p2-semantics.
> 
> Julian, do you want to sketch that out so people can have a look?
> 
> Cheers,
> 
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 Apr 2014 09:13:38 +0200

> Re-visiting this; I still think we can close #424 with no action. Any disagreement?

I got distracted by the other gzip discussion.

I really still believe that we should try to improve the situation; just 
because we can't require it for all chains of intermediaries doesn't 
mean we shouldn't ask for support in origin servers...

---

From: Martin Thomson <[email-masked]>
Date: Fri, 25 Apr 2014 09:09:28 -0700

On 25 April 2014 00:13, Julian Reschke <[email-masked]> wrote:
> because we can't require it for all chains of intermediaries doesn't mean we
> shouldn't ask for support in origin servers...

Does the T-E thing help?

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 26 Apr 2014 11:40:06 +1000

On 25 Apr 2014, at 5:13 pm, Julian Reschke <[email-masked]> wrote:

> I really still believe that we should try to improve the situation; just because we can't require it for all chains of intermediaries doesn't mean we shouldn't ask for support in origin servers...

"ask" and "require" are very different things... what are you thinking of in terms of text?

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Sat, 26 Apr 2014 09:00:16 +0200

> "ask" and "require" are very different things... what are you thinking of in terms of text?

"to allow compression of big request payloads, origin servers SHOULD 
support gzip content coding in request messages"

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 26 Apr 2014 00:36:29 -0700

On Apr 26, 2014, at 12:00 AM, Julian Reschke wrote:
> "to allow compression of big request payloads, origin servers SHOULD support gzip content coding in request messages"

I don't think that is appropriate.  Content-Encoding is generally not
governed by the server -- it is a characteristic of the representations,
so it will be determined by the resource owner's desires and not by the
protocol engine.  An origin server cannot implement that SHOULD even if
the developers wanted to, since it would interfere with method semantics.

....Roy

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 26 Apr 2014 21:25:49 +1200

> the developers wanted to, since it would interfere with method semantics.

Ahh.. transfer coding to the rescue.

Amos

---

From: Julian Reschke <[email-masked]>
Date: Sat, 26 Apr 2014 18:03:55 +0200

> the developers wanted to, since it would interfere with method semantics.

Not convinced.

If it's a characteristic of the representation, why can't the client 
sending the representation decide on it?

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Sat, 26 Apr 2014 13:14:51 -0700

On 26 April 2014 09:03, Julian Reschke <[email-masked]> wrote:
> If it's a characteristic of the representation, why can't the client sending
> the representation decide on it?

They can, but it's not clear that anything we say will change whether
the server accepts it or not.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 28 Apr 2014 16:53:03 +1000

On 27 Apr 2014, at 2:03 am, Julian Reschke <[email-masked]> wrote:

> Not convinced.
> 
> If it's a characteristic of the representation, why can't the client sending the representation decide on it?

Because that would be a unilateral decision, just like the client deciding that it’s going to send application/foobar+baz to your resource.

Now, if the client were to be able to discover that the resource (NOT server) supported compressed request bodies, that’s a different thing. However, *waves hands* this is not the WG you’re looking for…

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Apr 2014 11:41:38 +0200

> the server accepts it or not.

So just because it's not clear that what we say will be followed we're 
not saying it?

If we *want* origin servers to support C-E gzip, we should say so.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Apr 2014 11:44:49 +0200

> Because that would be a unilateral decision, just like the client deciding that it’s going to send application/foobar+baz to your resource.

I don't understand the comparison.

A client can send any payload type it wants. The server can reject it if 
it doesn't understand it. This applies both to media types an content 
encodings.

What I'm looking for is to *encourage* servers to understand C-E gzip.

(And yes, the compression changes might address my use case, but I 
haven't looked into those yet)

 > ...

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 28 Apr 2014 19:48:15 +1000

I’m saying that the most concrete way of encouraging servers to accept content-encoded request representations is to give them a means of declaring their support for doing so — e.g., in HTML — not a generic SHOULD in a place that resource authors will never look. 

On 28 Apr 2014, at 7:44 pm, Julian Reschke <[email-masked]> wrote:

> A client can send any payload type it wants. The server can reject it if it doesn't understand it. This applies both to media types an content encodings.
> 
> (And yes, the compression changes might address my use case, but I haven't looked into those yet)
> 
> > ...
> 
> Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Apr 2014 11:58:06 +0200

> I’m saying that the most concrete way of encouraging servers to accept content-encoded request representations is to give them a means of declaring their support for doing so — e.g., in HTML — not…

In HTML?

---

From: Matthew Kerwin <[email-masked]>
Date: Mon, 28 Apr 2014 20:09:04 +1000

On 28 April 2014 19:58, Julian Reschke <[email-masked]> wrote:
​​

>> I’m saying that the most concrete way of encouraging servers to accept
>> content-encoded request representations is to give them a means of
>> declaring their support for doing so — e.g., in HTML — not a generic SHOULD
>> in a place that resource authors will never look.
>> ...
>>
>
> In HTML?
>
>
>
​<form action="/rsrc-that-accepts-gzip" method="POST"><input type="file"
name="f"></form>
​<p>Select a file to upload (gzip files will be automatically extracted)</p>

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Apr 2014 12:17:28 +0200

On 2014-04-28 12:09, Matthew Kerwin wrote:
> On 28 April 2014 19:58, Julian Reschke <[email-masked]
> <mailto:[email-masked]>>wrote:
> ​​
>
>         I’m saying that the most concrete way of encouraging servers to
>         accept content-encoded request representations is to give them a
>         means of declaring their support for doing so — e.g., in HTML —
>         not a generic SHOULD in a place that resource authors will never
>         look.
>         ...
>
>
>     In HTML?
>
>
>

How does this help when my client is not a browser?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 28 Apr 2014 20:45:58 +1000

On 28 Apr 2014, at 8:09 pm, Matthew Kerwin <[email-masked]> wrote:

> ​<form action="/rsrc-that-accepts-gzip" method="POST"><input type="file" name="f"></form>

True - but I was thinking of something like

<form action=“/foo” method=“POST” content-encoding=“gzip”>…</form>

Cheers,

---

From: Matthew Kerwin <[email-masked]>
Date: Mon, 28 Apr 2014 20:45:29 +1000

> How does this help when my client is not a browser?
​How does your non-browser client discover that the resource exists in the
first place, or can be POSTed or PUT to? That's the place to add that it
​can handle zipped files. Whether that be in the linking hypermedia, or
offline API documentation, or a new link extension in a Link header, etc.

---

From: Matthew Kerwin <[email-masked]>
Date: Mon, 28 Apr 2014 21:01:45 +1000

Apologies if I'm drifting off topic at all.

> <form action=“/foo” method=“POST” content-encoding=“gzip”>…</form>

That introduces a UI/UX problem; ​does a browser present the gzip support
to the human? And if so, how does the human choose between: here's a file
which is already gzipped / here's a file which you can gzip for me* /
here's a file, don't gzip it?

* urgh, and is this any better than dynamic C-E in responses?

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 28 Apr 2014 21:22:51 +1000

On 28 Apr 2014, at 9:01 pm, Matthew Kerwin <[email-masked]> wrote:

> That introduces a UI/UX problem; ​does a browser present the gzip support to the human? And if so, how does the human choose between: here's a file which is already gzipped / here's a file which you can gzip for me* / here's a file, don't gzip it?

I wasn’t thinking it would; rather, it’s just a sign that the browser can gzip-encode the form when it submits it.

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Apr 2014 13:22:33 +0200

On 2014-04-28 12:45, Matthew Kerwin wrote:
> ...
> ​How does your non-browser client discover that the resource exists in
> the first place, or can be POSTed or PUT to? That's the place to add

HEAD? PROPFIND? AtomPub?

> that it ​can handle zipped files. Whether that be in the linking
> hypermedia, or offline API documentation, or a new link extension in a
> Link header, etc.
> ...

Yes, many ways to do that. But there should be a single way, so that 
middleware can do it automatically.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 28 Apr 2014 21:23:27 +1000

On 28 Apr 2014, at 9:22 pm, Julian Reschke <[email-masked]> wrote:

> Yes, many ways to do that. But there should be a single way, so that middleware can do it automatically.

As discussed, “middleware can do it automatically” and content-encoding don’t mix so well...

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Apr 2014 13:31:16 +0200

> As discussed, “middleware can do it automatically” and content-encoding don’t mix so well...

It's an issue for server->client, but not the other way around... 
(unless I'm missing something?)

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 29 Apr 2014 08:33:04 +0200

On Mon, Apr 28, 2014 at 01:22:33PM +0200, Julian Reschke wrote:
> >???How does your non-browser client discover that the resource exists in
> >that it ???can handle zipped files. Whether that be in the linking

In HTTP/1.1, we have 100-continue which would be the perfect fit for this.
The client waits for the server's agreement to send contents, and the
server could advertise its supported compression algorithms (both T-E and
C-E) in the 100-continue. And the benefit is that if an intermediary needs
to scan this content, it sends the 100 itself and will advertise what it
supports.

I don't know how we could translate that into 2.0 though.

Willy

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 29 Apr 2014 16:38:12 +1000

> I don't know how we could translate that into 2.0 though.
​T-E negotiation is replaced by a setting, and settings are sent as soon as
the connection is established, so that's already solved.​ I don't know how
a server could advertise support for content-encoded data within the
protocol.