Subject: HTTP/2 vs 1.1 semantics: intermediate codes

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Jun 2014 09:16:44 +0200

Hi there,

the current HTTP/2 spec currently points out that there are HTTP/1.1 
features that are removed, but that there are HTTP/2-specific ways to do 
things better.

I'm mostly ok with that, but think that the reasoning for the 1xx codes 
is really weak.

The main point of 1xx codes (other than expect-100/continue) is that 
servers can return status *and* header field while the request is 
processing. I agree that this isn't used a lot today (maybe not at all), 
but what is the replacement in HTTP/2?

Is there a technical reason why we can't just allow them in HTTP/2?

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 12 Jun 2014 09:44:19 +0200

Hi Julian,

> Is there a technical reason why we can't just allow them in HTTP/2?

Well, the only two 1xx we have now are directly used to fill a miss
in connection management in 1.1. I'd say that 100 is more or less a
poor man's flow control in that it limits sending when not necessary,
and 101 is directly related to the connection itself. Their support
is already messy in many 1.1 implementations. While I'm not seeing
any technical reason for not allowing them, I'm not seeing the need
to have them either, but I suspect that their semantics are never
easy to deal with and could mostly lead to wrong or partial
implementations like we used to have in 1.1.

Do you have a use case in mind where it could really make a difference
to have them ?

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Jun 2014 09:53:57 +0200

> Do you have a use case in mind where it could really make a difference

I kind of liked the ideas behind 102 (which used the message for 
progress reporting).

My preference would be not to break 1.1 features that aren't broken 
unless they clearly make HTTP/2 more complex. Is this the case here? At 
least we shouldn't claim we have a better replacement if we don't.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 12 Jun 2014 10:41:37 +0200

> I kind of liked the ideas behind 102 (which used the message for 

I don't remember it to be honnest, I'll have to take a look.

> least we shouldn't claim we have a better replacement if we don't.

I agree with that principle. At the same time I think that if we can do
without it's still better just to avoid carrying some of the interoperability
issues we had (eg: clients don't wait too long for 100-continue, intermediaries
have to consume all of them even if multiple responses are sent, etc).

Willy

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Jun 2014 10:48:10 +0200

> have to consume all of them even if multiple responses are sent, etc).

But that's a problem specific to 100, right? I'm totally OK with that 
one being killed.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 12 Jun 2014 10:52:13 +0200

On Thu, Jun 12, 2014 at 10:48:10AM +0200, Julian Reschke wrote:
> But that's a problem specific to 100, right?

Yes clearly.

> I'm totally OK with that one being killed.

Then maybe you're right and we should allow 1xx to pass and redefine
the semantics there when codes are unknown from the client (ie:
currently 1xx cannot fall back to the same behaviour as 100 contrary
to other codes).

Willy

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Jun 2014 11:55:15 +0200

> currently 1xx cannot fall back to the same behaviour as 100 contrary

Good point. I think we'll need start collecting issues for RFC7230bis.

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Jun 2014 10:07:37 -0700

> Is there a technical reason why we can't just allow them in HTTP/2?

The addition of 1xx codes has been discussed at some length at interim
meetings.  Various options have been proposed, though none were
particularly appealing.

The simple and obvious solution is to allow for multiple header
blocks.  Those with 1xx status codes would be ignored.  Then we would
have to deal with 100 and 101, which we positively don't want.  (Yes,
there have been some people arguing for 100, but I think we have
consensus on that point.)

In the 20+ years of HTTP, we've defined 3 1xx codes in total.

Of those,
  a. HTTP/2 provides a far superior alternative to 100
  b. HTTP/2 does not need 101.
  c. 102 has been long deprecated.

So while I can agree that the capability is interesting from a
theoretical standpoint, it's quite hard to justify spending effort on
a feature that is some combination of not needed, not wanted and not
used.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Jun 2014 19:12:54 +0200

> meetings.  Various options have been proposed, though none were

When? Minutes?

> consensus on that point.)

Sounds good to me.

> a feature that is some combination of not needed, not wanted and not

Chicken-and-egg. APIs do not give access to 1xx codes, so nobody is 
using them right now.

The same is true for trailers - why are they still in?

My th

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Jun 2014 10:18:04 -0700

> The same is true for trailers - why are they still in?

Personally, I'd rather have them removed.  But such is the nature of
the process.

---

From: Jason Greene <[email-masked]>
Date: Thu, 12 Jun 2014 12:56:34 -0500

On Jun 12, 2014, at 12:12 PM, Julian Reschke <[email-masked]> wrote:

-snip-

> Chicken-and-egg. APIs do not give access to 1xx codes, so nobody is using them right now.

That’s not entirely accurate. Expect-100 is used by default with all MS .NET Web Services. It’s supported (although usually not on by default) by various Java frameworks as well.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Jun 2014 20:06:11 +0200

> That’s not entirely accurate. Expect-100 is used by default with all MS .NET Web Services. It’s supported (although usually not on by default) by various Java frameworks as well.

What I meant is that the 1xx are not exposed. Neither in the servlet 
API, nor in XHR (these are the APIs I care about).

Best regards, Julian

---

From: Jason Greene <[email-masked]>
Date: Thu, 12 Jun 2014 15:11:09 -0500

On Jun 12, 2014, at 1:06 PM, Julian Reschke <[email-masked]> wrote:

> What I meant is that the 1xx are not exposed. Neither in the servlet API, nor in XHR (these are the APIs I care about).

I think with XHR the expectation was that the browser is/should be in control of this.

As to standalone client size, the JDK HttpUrlConnection lets you use expect 100, as well as a bunch of common client libraries like httpclient. And of course, MS WS clients. IIRC curl even sends Expect 100s on posts.

On the server side, in particular with Servlet, it’s usually handled for you according to some configured policy. As an example, you can often set header restrictions (like content length), or authorization requirements and these are enforced immediately after receiving the headers. Additionally some impls will hold off the 100 until your first body read, actually allowing the servlet to reject early before the 100 is sent. Then there is also hooks where you can register specific custom handling code.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Jun 2014 22:51:48 +0200

> As to standalone client size, the JDK HttpUrlConnection lets you use expect 100, as well as a bunch of common client libraries like httpclient. And of course, MS WS clients. IIRC curl even sends Ex…

I meant 1xx codes other that 100.

> ...

Best regards, Julian