Subject: Getting to Consensus on 1xx Status Codes (#535)

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 Jul 2014 15:40:07 +1000

<https://github.com/http2/http2-spec/issues/535>

So far, we've had two proposals for this issue;

a) Accommodating non-final responses in HTTP/2
    See Julian's proposal at <https://gist.github.com/reschke/48ec30b0ac9d012b8b4e> for an idea of how this would look in the spec.

b) Publishing a separate document deprecating 1xx status codes
    Thereby preventing the establishment of new ones (HTTP/2 already defines how to deal with 100, and 101 is not relevant to this protocol. 102 was dropped by its primary use case, WebDAV, here: <http://tools.ietf.org/html/rfc4918#appendix-F.3>)

I'd like to hear:

1) Your preferred outcome (if any)
2) Whether you can live with the other option, and if not, why

"I have no preference" is useful information too.

If you indicate you can't live with one (or both) of the options, you MUST give a detailed, relevant reason as to why; omitting the reason means your "can't live with" will be ignored.

Thanks,

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

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 17 Jul 2014 16:29:00 +1000

My preference is for 100 support.  Julian'd draft looks ok except that it
excludes support for 100.   I'm fine with it excluding support for 101 and
102.

If 100 had been deprecated in rfc723x, then I'd would have lived with
dropping it better, as I could have just dropped it entirely from the
server and referred broken applications to the RFC.   But it is not
deprecated for current h1 usage, so end points that will support both h1/h2
will need to have 100 continue support anyway.  Making it dependent on the
transport probably increases the complexity rather than decreases it.

So I could live with b) if that document is targeted to both h1 and h2, so
there is some prospect that we can drop support entirely in a few
years.

regards

On 17 July 2014 15:40, Mark Nottingham <[email-masked]> wrote:

>     See Julian's proposal at <
> https://gist.github.com/reschke/48ec30b0ac9d012b8b4e> for an idea of how
> this would look in the spec.
>
>     Thereby preventing the establishment of new ones (HTTP/2 already
> defines how to deal with 100, and 101 is not relevant to this protocol. 102
> was dropped by its primary use case, WebDAV, here: <
> http://tools.ietf.org/html/rfc4918#appendix-F.3>)
>
> I'd like to hear:
>
> If you indicate you can't live with one (or both) of the options, you MUST
> give a detailed, relevant reason as to why; omitting the reason means your
> "can't live with" will be ignored.
>
> Thanks,
>
> --

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 17 Jul 2014 07:32:06 -0400

Mark,

I support *both* proposals, with B deprecating *new* 1xx status codes.  See below...

> If you indicate you can't live with one (or both) of the options, you MUST give a detailed, relevant reason as to why; omitting the reason means your "can't live with" will be ignored.

I originally believed that supporting Expect: 100-continue and 100 responses in HTTP/2 was unnecessary, and have expressed that opinion to the list on several occasions in the past.  The main use of 100-continue is to provide a relatively safe, early abort of POST and PUT requests, and IPP uses this extensively to prevent the needless transmission of gigabytes of print data when a Print-Job request requires authentication.  In HTTP/2, the framing layer provides a suitable alternative where the server can reset the stream used for the POST or PUT request - in effect, we have a "stop, don't send more" signal in HTTP/2 vs. a "go ahead" signal in HTTP/1.1.  Both happen to work for IPP over HTTP/2, but semantically they are different.

Recent discussions of supporting HTTP/1.1 to HTTP/2 proxies/gateways has highlighted this semantic difference, and it does sound like bridging HTTP/1.1 Expect semantics to HTTP/2 will be basically impossible without serious use of duct tape and fair amount of luck.  So I support Julian's proposal (option A) to add non-final response HEADER frames to HTTP/2.

Regarding option B:

- We should only deprecate *new* 1xx status codes.
- We should formally deprecate 102 - 4918's mention of it being removed in an appendix isn't particularly visible. We can reference RFC 4918 for the deprecation but we should actually remove 102 from the registry (or mark it as deprecated).
- For 100 status codes, we can clarify that they must only be sent by a HTTP server if the client includes the Expect: 100-continue header in its request.  Thus, the client (application) is stating its ability to handle non-final responses by requesting the non-final response behavior.
- We can also provide interoperability recommendations for 100-continue: clients SHOULD NOT wait indefinitely for a 100 response before sending the request message body.
- I believe that the HTTP/2 document addresses status code 101 sufficiently for HTTP/2.  Perhaps the B document can reference HTTP/2 so that it is clear that 101 is only for HTTP/1.x.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Jul 2014 13:53:25 +0200

> 1) Your preferred outcome (if any)

a) (assuming my proposal already is sufficient or can be made to work 
easily)

> 2) Whether you can live with the other option, and if not, why

I could live with the other option, but I firmly believe that the 
ability to send non-final responses could be very useful. Also I just 
don't see an equivalent way to do this in HTTP/2 that maps to common 
HTTP semantics.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Jul 2014 14:02:18 +0200

On 2014-07-17 13:32, Michael Sweet wrote:
> ...

Why would we actually want to deprecate them? Do we have a standardized 
replacement?

> - We should formally deprecate 102 - 4918's mention of it being removed in an appendix isn't particularly visible. We can reference RFC 4918 for the deprecation but we should actually remove 102 fr…

What's the benefit of removing it from the registry?

> - For 100 status codes, we can clarify that they must only be sent by a HTTP server if the client includes the Expect: 100-continue header in its request.  Thus, the client (application) is stating…

Is this a proposal for an erratum for RFC 7231, or specific to HTTP/2?

> - We can also provide interoperability recommendations for 100-continue: clients SHOULD NOT wait indefinitely for a 100 response before sending the request message body.

RFC 7231 already says:

"A client that sends a 100-continue expectation is not required to wait 
for any specific length of time; such a client MAY proceed to send the 
message body even if it has not yet received a response. Furthermore, 
since 100 (Continue) responses cannot be sent through an HTTP/1.0 
intermediary, such a client SHOULD NOT wait for an indefinite period 
before sending the message body." -- 
<http://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.5.1.1.p.7>

> - I believe that the HTTP/2 document addresses status code 101 sufficiently for HTTP/2.  Perhaps the B document can reference HTTP/2 so that it is clear that 101 is only for HTTP/1.x.

Actually, it seems that it's silent on what the semantics of an 1xx in a 
HTTP/2 headers frame is. Valid? Non-final? If we keep 1xx out of HTTP/2, 
we should clearly state what it means. Right now we say

  "An intermediary that gateways HTTP/2 to HTTP/1.1 MUST discard all 
other 1xx informational responses."

but what about the opposite case?

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 17 Jul 2014 12:27:57 +0000

>So far, we've had two proposals for this issue;

I buy the argument that there are valid cases for what 100-Continue
does in HTTP/1:  "I'll only send the body when you tell me to."

It's not obvious to me that 100-Continue is the best way to implement
this, since we could actually improve the way it works over the
rather arbitrary HTTP/1 semantics.

We could get the same effect, much more rigidly defined, with a
single bit on HEADERS which means "I won't send the entity body
until you tell me to."  The "tell me to" bit can be done any number
of trival ways, down to ".. until you send me a WINDOW_UPDATE on
this stream".

That seems far preferable to me.

That leaves 101 for Upgrade: and I'm not sure I see the need for
that at all.

I propose that we declare that HTTP/2 can only be "upgraded" to
protocols which retain it's framing layer.  Given that HTTP/2 is
arrived at via either Upgrade: or TLS negotiation, any protocol
that does not share HTTP/2's framing layer would be better of not
taking the detour over HTTP/2 in the first place.

Doing that, a SETTINGS can tell which protocols are supported
at the receiver, and by giving these protocols half-open frames
different from HEADERS and PUSH-PROMISE, these protocols can
run in parallel with HTTP/2, rather than as replacements for it.

That means we don't need 101 either.

That also seems far preferable to me.

So this is my position:

I'm against supporting 1xx responses the way HTTP/1 does.

I'm for adding the functionaly they offer in way that makes
HTTP/2 a better protocol.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Jul 2014 14:38:36 +0200

> I'm against supporting 1xx responses the way HTTP/1 does.

FWIW, I do support that we don't need 101, and that we might be able to 
do 100 better.

However, that doesn't cover other cases of 1xx. Yes, I realize that 
there currently do not seem any, but I'm very unhappy to close an 
existing extension point without very good reasons.

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 17 Jul 2014 12:44:00 +0000

>existing extension point without very good reasons.

I understand your unhappiness, but invoke Gettys rules 1 & 3:

1. Do not add new functionality unless an implementor cannot complete
   a real application without it.

3. The only thing worse than generalizing from one example is
   generalizing from no examples at all.

I'll be happy to look at any concrete proposals if and when they
appear, but anything we define in a vacuum would be widely unimplemented
and therefore probably not work at all.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Jul 2014 14:51:18 +0200

>     a real application without it.

We're not talking about new functionality.

> and therefore probably not work at all.

The concrete proposal is to handle 1xx messages in HTTP/2 exactly the 
same way as in HTTP/1.1. HTTP/2 will need code (and specification) to 
deal with 1xx one way or another, and I believe my proposal has the 
property of being both simple and consistent with 1.1.

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 17 Jul 2014 12:55:56 +0000

>property of being both simple and consistent with 1.1.

And as I said:  I think that's a bad idea.

We can do 100 better, don't need 101 and we have no idea how any
future 1xx codes might or might not work anyway.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 17 Jul 2014 09:03:06 -0400

Julian,

On Jul 17, 2014, at 8:02 AM, Julian Reschke <[email-masked]> wrote:
> Why would we actually want to deprecate them? Do we have a standardized replacement?

First, because in the almost 20 years since RFC 1945 (HTTP/1.0) was published, we have only ever come up with three 1xx status codes, one of which has already been deprecated (102) due to lack of use/implementation, and another (101) that has been effectively been replaced by ALPN for HTTPS.  That tells me that 1xx status codes have limited usefulness.

Second, there are well-known interoperability limitations to 1xx status codes - clients cannot depend on end-to-end support through intermediaries, which is why any good HTTP client that uses Expect: 100-continue implements a short go-ahead timeout in case a 100 response is not received by/forwarded to the client, and why HTTP Upgrade has been rejected by many to support cleartext HTTP/2.0.

> What's the benefit of removing it from the registry?

Just so that people don't use it.  Even updating the registry to say "(deprecated in RFC 4918)" in the description will be useful since the only mention of 102 in RFC 4918 is buried in the appendix and RFC 2518 is the only thing you see in the registry.

> Is this a proposal for an erratum for RFC 7231, or specific to HTTP/2?

Erratum for RFC 7231, since it should apply to all versions of HTTP.

However, if we *do* publish a separate document about 1xx status codes then it might as well go there until/unless 7231 is updated.  (Best practice/implementor's guide documents are a good thing IMHO)

> "A client that sends a 100-continue expectation is not required to wait for any specific length of time; such a client MAY proceed to send the message body even if it has not yet received a response. Furthermore, since 100 (Continue) responses cannot be sent through an HTTP/1.0 intermediary, such a client SHOULD NOT wait for an indefinite period before sending the message body." -- <http://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.5.1.1.p.7>

OK, good - missed that (wish we still had a single document to find this stuff; I'll get used to it in time I'm sure...)

> Actually, it seems that it's silent on what the semantics of an 1xx in a HTTP/2 headers frame is. Valid? Non-final? If we keep 1xx out of HTTP/2, we should clearly state what it means. Right now we say
> 
> "An intermediary that gateways HTTP/2 to HTTP/1.1 MUST discard all other 1xx informational responses."
> 

Right, thus my comment about it being impossible to gateway HTTP/1.1 Expect semantics to HTTP/2.

(If we can actually come up with a solution that doesn't require intermediate HEADER frames with a :status 100 header, fine, but so far I don't think we have it.)

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Jul 2014 15:08:36 +0200

> future 1xx codes might or might not work anyway.

The last part doesn't make any sense.

My proposal is to treat them *exactly* as in 1.1.

What exactly do you mean by "might or might not work"?

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 17 Jul 2014 13:14:58 +0000

>What exactly do you mean by "might or might not work"?

We've seen only one new additional 1xx code in ages and we already
regretted it.

I'm against adding a "contigency plan" to HTTP/2 on the unlikely
probability that 103 will ever happen, given that 1xx already works
like shit in HTTP/1.

Nobody says we cannot add support for 1xx later, if it suddenly
transpires to be a killer-app for something.

In the meantime I propose we add a flag to HEADERS (ON_YOUR_SIGNAL
?) and give it the meaning "I'll send the body when you send me a
WINDOWS UPDATE" and close the long sad saga of 1xx dysfunctionality.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Jul 2014 15:22:25 +0200

> Second, there are well-known interoperability limitations to 1xx status codes - clients cannot depend on end-to-end support through intermediaries, which is why any good HTTP client that uses Expec…

All intermediaries need to do is implement what the HTTP 1.1 RFCs tell 
them with respect to handling of non-final messages. An intermediary (or 
client) that fails to do the right thing is broken, and a bug should be 
reported.

(I agree wrt 100 and 101, but these are not what I'm concerned about)

> Just so that people don't use it.  Even updating the registry to say "(deprecated in RFC 4918)" in the description will be useful since the only mention of 102 in RFC 4918 is buried in the appendix…

RFC 4918 does not deprecate 102; it just doesn't define it anymore (4918 
was the transition to Draft Standard, and we didn't want to include 
things that currently were not implemented). The status is the same as 
for, for instance, the PATCH method which wasn't in RFC 2616.

So no, the intent wasn't to discourage use of 102.

> Erratum for RFC 7231, since it should apply to all versions of HTTP.

OK, then please clarify in *how* this is an erratum. We currently say:

"If the request did not contain an Expect header field containing the 
100-continue expectation, the client can simply discard this interim 
response." -- 
<http://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.6.2.1.p.3>

Isn't that sufficiently clear?

> (If we can actually come up with a solution that doesn't require intermediate HEADER frames with a :status 100 header, fine, but so far I don't think we have it.)

So that proposal is sort of consistent with mine, except that you want 
to special-case 100. My preference would be to stay generic.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 17 Jul 2014 15:25:59 +0200

Hi Mark,

> "I have no preference" is useful information too.

I must say I don't have a strong preference. I dislike 1xx but at the
same time they exist and I suspect that a 2->1 gateway will be a bit
harder to implement without them. On the other hand, 2.0 agents which
don't need them will have to gracefully deal with them if we keep them.
Everything goes down to whether these codes have real semantics or are
just for framing. IMHO Julian tends to have a good flair on semantics
related issues and I would not be very surprized if we finally came up
with a concrete example of valid use that is not transposable in 2.0.
If either solution does not work over two protocol conversions, then
we should keep the other one :

   1.1 client ----> 1-2 proxy ------------> 2-1 gateway ---> 1.1 server
   2.0 client ----> 2-1 proxy ------------> 1-2 gateway ---> 2.0 server

The first case may break WS clients if the 1-2 proxy does not have other
option than forwarding in 2.0. It may also prove not very convenient to
handle certain expect failures between the client and the server. But
that's just a feeling.

Hoping this brings some fuel to the discussion.

Willy

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Jul 2014 15:29:41 +0200

> We've seen only one new additional 1xx code in ages and we already

Yes, and no (we didn't regret it).

> probability that 103 will ever happen, given that 1xx already works

Are you referring to 100, 101, or other 1xx codes?

> transpires to be a killer-app for something.

Chicken-and-egg: if you can't use 1xx over HTTP/2, it's very unlikely 
that that new status code 103 will ever be defined.

> WINDOWS UPDATE" and close the long sad saga of 1xx dysfunctionality.

That's a problem specific to *100*.

Best regards, Julian

---

From: Michael Sweet <[email-masked]>
Date: Thu, 17 Jul 2014 09:30:19 -0400

I'd just call the flag "EXPECT_WINDOW_UPDATE" and document that it corresponds to the Expect: 100-continue semantics of HTTP/1.1.

We'll still need to define the HTTP/1.1 gateway behavior, e.g., a 2.0 to 1.1 gateway needs to implement a timeout that sends a WINDOW_UPDATE frame if it doesn't see a 100 response in a timely manner.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 17 Jul 2014 13:34:29 +0000

>Are you referring to 100, 101, or other 1xx codes?

All of the above.

>that that new status code 103 will ever be defined.

And that would be perfectly fine with me:  Imagine the hazzle
anybody doing so would have to get it working with HTTP/1...

>That's a problem specific to *100*.

yes.

101 isn't needed if we sensibly declare that updates to HTTP/2 use
the same frame structure.

And 1xx apart from those two, I'll not even start to think about
until somebody concretely tells us what they are for and what
they should do.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 17 Jul 2014 13:36:10 +0000

In message <[email-masked]>, Michael Sweet writes:

>I'd just call the flag "EXPECT_WINDOW_UPDATE" and document that it
>corresponds to the Expect: 100-continue semantics of HTTP/1.1.

Works for me.

>We'll still need to define the HTTP/1.1 gateway behavior, e.g., a 2.0 to
>1.1 gateway needs to implement a timeout that sends a WINDOW_UPDATE
>frame if it doesn't see a 100 response in a timely manner.

The HTTP/1.1 spec already tells you that.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Jul 2014 15:52:55 +0200

> until somebody concretely tells us what they are for and what

They are non-final, and informational. Just pass them along. No rocket 
science at all.

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 17 Jul 2014 14:05:49 +0000

>They are non-final, and informational. Just pass them along. No rocket 

They are non-existent and incompatible with HTTP/1.  Just forget them.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 17 Jul 2014 11:36:48 -0400

Julian,

On Jul 17, 2014, at 9:22 AM, Julian Reschke <[email-masked]> wrote:
> "If the request did not contain an Expect header field containing the 100-continue expectation, the client can simply discard this interim response." -- <http://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.6.2.1.p.3>
> 

It specifies client behavior, but does not recommend a server behavior that improves interop, namely that a server should only respond with a 100 status if the client asks for it.  I know that wasn't the original explicit intent, but given 20 years of implementation experience it is reasonable to document "what works" vs. "what was specified".  It also allows HTTP/2 to support a specific semantic intent vs. a vague "1xx status code at any time" policy that has proven interoperability issues in HTTP/1.x.

> So that proposal is sort of consistent with mine, except that you want to special-case 100. My preference would be to stay generic.

I prefer explicit semantics that promote interoperability and guaranteed functionality.  We already have three 1xx status codes with drastically different semantics, two that can be ignored safely (100, 102) and one that can't (101).  We also have almost 20 years of HTTP that has shown no real growth or experimentation with 1xx status codes, while 2xx, 3xx, 4xx, and 5xx have been widely extended and are supported with clear semantics even if the client doesn't understand a particular status code.

So yes I am OK with using an intermediate HEADERS frame being used to express the semantic for a 100 response in HTTP/2 which can be safely ignored by a client or intermediary, but I am NOT OK with leaving the door open for another 101-like response that cannot be safely ignored.  Thus, if instead we decide to use an EXPECT_WINDOW_UPDATE bit in the client's HEADERS frame and use the server's WINDOW_UPDATE on a stream as the replacement for a 100 response, that works for me too because it preserves the well-define semantics of using Expect: 100-continue in a client request to elicit a "go ahead" response from the server if the request can continue to be submitted.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 17 Jul 2014 11:38:31 -0400

> The HTTP/1.1 spec already tells you that.

As a HTTP/1.1 client, not as a HTTP/2 gateway.

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 18 Jul 2014 03:38:36 +1200

On 18/07/2014 1:36 a.m., Poul-Henning Kamp wrote:
> In message Michael Sweet writes:
> 

Maybe I missed it. Where does HTTP/1.1 spec mention WINDOW_UPDATEs exactly?

The HTTP/2 spec needs to say *how* the mechanism maps to
Expect:100-continue at both gateway directions or we will end up with
implementations which forget or omit one half the mechanism. Thus
repeating the 100-continue problem all over again.

Amos

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 18 Jul 2014 03:53:25 +1200

> "I have no preference" is useful information too.

Given the two I prefer A.
 Nit: "arent't suitable" -> "are not suitable"

I would also like to see A modified to include the clarification
discussed on the gateway operations mapping the status codes 1.1->2 and
2->1.1 using WINDOW_UPDATE. With text explicitly deprecating the status
100 and 101 (only) in HEADERS.

Amos

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Jul 2014 09:45:21 -0700

> 1) Your preferred outcome (if any)

I've described this elsewhere.

We've very few examples upon which to base this decision: 100 is
generally just bad, 101 is generally agreed to be unnecessary, and 102
is deprecated.  But the pattern that I'm seeing here is that these are
functions that generally related to protocol mechanics.

The reason we agreed that 100-continue was OK to drop was that we had
something roughly equivalent in WINDOW_UPDATE.  The reason that we all
agree 101 is unnecessary is that we have ALPN and Upgrade (from
HTTP/1.1).

My hypothesis is that mechanisms that operate at this level are best
addressed at the framing layer and should be constructed there.
Julian's proposal ports a *mechanism* from HTTP/1.1, not a feature.

I think that we're fine as we are now.

If someone wants to define 107 (Gossip about Sheryl's choice in
clothing), then that's how that might manifest in HTTP/1.1, but we can
just make an extension frame for that in HTTP/2.  And I'm guessing
that the HTTP/2 extension will deploy with a much higher success rate.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Jul 2014 19:57:05 +0200

> that the HTTP/2 extension will deploy with a much higher success rate.

The drawbacks are:

- you'll need one extension per status code

- 1.1/2 gateways won't know how to translate new codes

...unless we define a generic extension that can transport them all.

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Jul 2014 11:02:58 -0700

> ...unless we define a generic extension that can transport them all.

I think that you've caught on.  I can't guarantee that it would be a
perfect fit for all potential use cases, but I don't have a crystal
ball either.

---

From: Nicholas Hurley <[email-masked]>
Date: Thu, 17 Jul 2014 11:09:32 -0700

> 1) Your preferred outcome (if any)

My preferred outcome is to drop 1xx entirely. We already have the existing
use cases of it covered (or removed from use), so there's no backwards
compatibility issues. (Not that there would have been much, given that 1xx
isn't terribly well supported in the wild, anyway.) And the general space
that 1xx covers seems like something that should be handled at the framing
layer in h2 - in other words, things that are protocol workings.

If anyone wants to support some future 1xx-like thing, that sounds like the
perfect match for an extension. Call the extension frame
"112_PLINY_THE_YOUNGER_DIED" for all I care.

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 18 Jul 2014 09:59:02 +1000

So at least it looks like all the voices here can live with 100 semantics.

For my own part, I see merit in both proposal: 1) implement exactly as in
rfc723x   vs 2) new mechanism designed to support 100 only, but not 1xx

>From an implementation point of view,  I probably prefer the former as it
keeps better separation of the layers, in that sending a 1xx carrying
header is a decision made above the framing layer.

The second is kind of possible to implement, but is not exactly the same
semantic and will blur the boundaries and complicate the flow control
algorithm.  On receiving a header with the proposed flag, the reverse flow
control window will need to be set to 0.   This is now different from 100
semantic, as h1 allows the body to be sent immediately or after a timeout,
where this prevents it being sent.    We will then need the request to be
dispatched for handling and some how communicate all the way down the the
flow control layer when it is possible to increase the window.    I'm not
that keen on tunnelling semantic all the way from the application layer
down to the flow control algorithm.

My server currently has all the logic to say "send a 100 message and keep
the request state open".  That is really easy to adapt to sending a headers
frame with 100 in it.    It can of course be plumbed into the flow control
algorithm, but it will not be as simple or clear.

So I guess in the end, I prefer keeping RFC723x semantic exactly.

cheers

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Jul 2014 17:12:40 -0700

> So at least it looks like all the voices here can live with 100 semantics.

That's taking liberties.  I think that Mark will make that sort of
assessment.  And I note that the number of participants is pretty low.

> I prefer keeping RFC723x semantic exactly.

So you've said.  But you keep talking about mechanisms rather than
semantics.  It seems to me like you want a near-perfect facsimile of
the mechanism too.

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 18 Jul 2014 10:25:23 +1000

> assessment.  And I note that the number of participants is pretty low.

by "here" I meant in this thread.   I was just trying to focus in on what I
saw as the remaining differences.

> So you've said.

Well no.   I've previously said I see use-case for the 100 semantic, but
not expressed a preference for a mechanism to transport it.      I'm
certainly not opposed to a new mechanism for the semantic, but I'm a bit
cautious about using the flow control window as the mechanism.

>  But you keep talking about mechanisms rather than

No - I want the semantic.   But I see two proposals have been made for a
mechanism and I evaluated how they would affect my implementation.

As I already have code that implements the existing RFCs for 100 support in
h1, so it is simplest for me (and I expect a lot of others) to adapt that
to 100 handling for h2.  For jetty, most of the 100 handling is above the
framing layer and I have to explicitly disable it for non HTTP transports
such as SPDY, FCGI etc.

The jetty mechanism inspects request headers and sends a non final response
"frame" if the application signals it wants the body.    A h2 mechanism
similar to that, but that is incapable of carrying 1xx messages is fine by
me.  I just would like it at the same semantic level in the protocol.

A mechanism that uses framing flags and adjusting the flow control
algorithm to get similar but not exact semantics simply does not fit.   I
will end up implementing 2 similar but different 100 continues mechanism
depending on the transport layer - ugh!

regards

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 18 Jul 2014 10:42:47 +1000

Greg,

You're talking about a separable issue here; Julian's proposal is to maintain our current approach to 100 (Continue), and that has had very broad support within the WG.

Cheers,

On 17 Jul 2014, at 4:29 pm, Greg Wilkins <[email-masked]> wrote:

> 
> My preference is for 100 support.  Julian'd draft looks ok except that it excludes support for 100.   I'm fine with it excluding support for 101 and 102.
> 
> If 100 had been deprecated in rfc723x, then I'd would have lived with dropping it better, as I could have just dropped it entirely from the server and referred broken applications to the RFC.   But it is not deprecated for current h1 usage, so end points that will support both h1/h2 will need to have 100 continue support anyway.  Making it dependent on the transport probably increases the complexity rather than decreases it.
> 
> So I could live with b) if that document is targeted to both h1 and h2, so there is some prospect that we can drop support entirely in a few years.     
> 
> regards
> 
> 
> 
> 
> 
> 
> 
>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 18 Jul 2014 10:54:19 +1000

On 18 Jul 2014, at 10:52 am, Greg Wilkins <[email-masked]> wrote:

> 
> Mark,
> 
> I don't see how my response is a separate issue?  You asked for a preference between a) and b) and I gave it.
> 
> I'm fine with a), but see no point unless it supports 100.    I'm OK with b), but see no point unless it deprecates 1xx for all http, not just h2

OK, that's helpful. (b) is explicitly for all of HTTP, not just HTTP/2 -- hence, it's in a separate document.

> In short the WG should either support 1xx or not and that should apply regardless of transport and I can live with anything that works towards that.    Supporting it sometimes but not others is what I object to.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 18 July 2014 10:42, Mark Nottingham <[email-masked]> wrote:
> Greg,
>

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 18 Jul 2014 10:52:59 +1000

Mark,

I don't see how my response is a separate issue?  You asked for a
preference between a) and b) and I gave it.

I'm fine with a), but see no point unless it supports 100.    I'm OK with
b), but see no point unless it deprecates 1xx for all http, not just h2

In short the WG should either support 1xx or not and that should apply
regardless of transport and I can live with anything that works towards
that.    Supporting it sometimes but not others is what I object to.

On 18 July 2014 10:42, Mark Nottingham <[email-masked]> wrote:

> Greg,
>
> You're talking about a separable issue here; Julian's proposal is to
> maintain our current approach to 100 (Continue), and that has had very
> broad support within the WG.
>
> Cheers,
>
>
> > My preference is for 100 support.  Julian'd draft looks ok except that
> it excludes support for 100.   I'm fine with it excluding support for 101
> and 102.
> >
> > So I could live with b) if that document is targeted to both h1 and h2,
> so there is some prospect that we can drop support entirely in a few years.
> >
> > regards
> >
> >
> >
> >
> >
> >
> >
> >
> > If you indicate you can't live with one (or both) of the options, you
> MUST give a detailed, relevant reason as to why; omitting the reason means
> your "can't live with" will be ignored.
> >
> > Thanks,
> >
> > --

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 18 Jul 2014 14:56:20 +1200

> - you'll need one extension per status code

OR, group of codes. ie 107-110 Gossip about Sherly, Andys RSS feed, Bobs
blog.

> - 1.1/2 gateways won't know how to translate new codes

In accordance with 1xx semantics for compatibility with 1.0 the default
action is drop 1xx. This can be defined for h2 gateways.

> ...unless we define a generic extension that can transport them all.

Or specify that they can be dropped at any time by gateways receiving them.

I am currently planning to implemet 2->1.1 gateway with WINDOW_UPDATE=0
and Expect:100-continue on POST and PUT. Still unsure of some 1.1->2
cases, but with increased 100-continue usage implied by 2->1.1 it seems
more likely to be useful and/or needed.
If the WG can come up with a better mechanism than WINDOW_UPDATE (or
HEADERs+:status=100 to translate the mechanism I will look at it.

Amos

---

From: Roberto Peon <[email-masked]>
Date: Thu, 17 Jul 2014 22:46:51 -0700

Julian's proposal has the problem of allowing for/requiring headers which
are not flow controlled, and with no restriction on the number.
That makes me feel uncomfortable, however, if that could be reasonably
addressed I'd be comfortable supporting it.
Use of HEADERS in this way would potentially preclude other uses of
intermediate HEADERS, and would complicate the current spec.

I still feel support for 1XX is mostly unnecessary for H2, so option #2 (as
I understand it) is preferable.
-=R

---

From: Julian Reschke <[email-masked]>
Date: Fri, 18 Jul 2014 08:36:10 +0200

> You're talking about a separable issue here; Julian's proposal is to maintain our current approach to 100 (Continue), and that has had very broad support within the WG.

Well, my proposal is for 1xx other than 100 or 101. I haven't thought 
about what's the best way to emulate expect/continue in HTTP/2.

Best regards, Julian

---

From: Roy T. Fielding <[email-masked]>
Date: Fri, 18 Jul 2014 10:19:10 -0700

My opinion hasn't changed.

If we don't support 100 then we can't ask the endpoint (not just the
next hop) to verify that it will process the data in a large upload before
sending that large upload.  I don't care if browsers don't use this feature.
It is commonly used in authoring environments for customers with large
data nodes (GIS and DAM).  h2 framing can only do the same if there are
no intermediaries.

If we don't support 101 then I can't upgrade from h2 to waka within h2,
which means we are dropping existing HTTP functionality (for no apparent
reason other than WG-arrogance that h2 is an end-protocol).  Upgrade
does work.  Reports that it does not are nothing more than repeated
myths based on old code that has no relevance to h2.

If we don't support 102 then we don't have a means of indicating
long-running status to the client without signaling a 203.  Note that
this code was requested before WebDAV, but was defined by them because
RFC2068 had already been published.  Swallowing the response
doesn't seem to support the server's intent.  And, yes, the code is
used in practice, most commonly with encapsulated legacy systems; e.g.,

  http://stackoverflow.com/questions/16890668/how-to-deal-with-102-response-in-lwpuseragent

If we don't support 1xx, in general, then h2 is less extensible than HTTP/1,
again for no apparent reason other than WG-arrogance that we'll get it right
the first time.

All of these codes have been implemented in practice.  I have used
them, interoperably, in both non-browser user agents and origin servers.
I would have used them in javascript as well if they were passed through
to the script consistently.

AFAICT, this working group is short on experience and too focused on
browser usage of HTTP.  Get over it.  Each of these codes have a purpose
and it does no harm to support that purpose even if you don't personally
need it. Don't remove features just because you haven't used them.
If you want to do that, feel free to do so in a protocol called SPDY.

The only reason we don't have more 1xx codes is because I haven't seen
a need for any more, and neither has anyone else.  How could that possibly
be seen as a negative for 1xx?  I also didn't see a need for any of the
other status codes defined since RFC2068, until someone showed that there
was a need. None of us are omniscient, which is why we have extensibility.
If you want a protocol to last a few decades, don't assume too much.

....Roy

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 18 Jul 2014 20:11:14 +0200

Hi,

> "can't live with" will be ignored.

Reading various people's use cases has finished to convince me that I'd
rather keep the 1xx semantics. The problem we have with 1xx is that in
HTTP/1.1 they are addressing both semantics and transport at the same
time. In H2, these two are much better split and pretending that the
framing will ensure their emulation is not a satisfying response especially
since framing is mostly hop-by-hop while their semantics is mostly
end-to-end. I don't care how it's implemented provided that it is not
conflated with the framing layer. We can even invent interim frames
that can be flow-controlled etc...

I think Roberto made a good point about flow control. I'm not really scared
about this given that there are rarely large headers in 1xx responses (if
any at all), but if we do the things, better do them correctly. That could
be one more reason for having a separate frame type from HEADERS, which
would basically be a flow-controlled HEADERS frame, or simply to have a
flag on the HEADERS frame to declare whether they're flow-controlled or
not (which could also help for the other cases where people used to worry
about this, but that's a different story).

So I had concerns about 1->2 and 2->1 gateway hacks without 1xx, but now
I'm pretty much convinced that we'd miss a useful HTTP/1.1 feature without
them eventhough a number of the participants here do not use them for
anything but flow-control and/or framing.

So that's A) for me.

Regards,
Willy

---

From: Michael Sweet <[email-masked]>
Date: Fri, 18 Jul 2014 15:20:56 -0400

Roy,

I think the issue *I* have with more 1xx status codes is that, thanks to the precedent set by 101, the recipient can't just ignore a 1xx status code it doesn't understand and wait for another response to come along.  And there is no guarantee that a particular status code is transmitted end-to-end - 101 is certainly a per-hop mechanism, and in my experience 100 is commonly dropped by proxies.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 18 Jul 2014 15:44:13 -0700

On Jul 18, 2014, at 12:20 PM, Michael Sweet wrote:

> Roy,
> 
> I think the issue *I* have with more 1xx status codes is that, thanks to the precedent set by 101, the recipient can't just ignore a 1xx status code it doesn't understand and wait for another response to come along.

An HTTP/1.1 recipient cannot ignore 101.  An Upgrade header isn't
going to pass though a proxy that doesn't understand 101, unless
the proxy doesn't implement Connection and deliberately violates the
standard by forwarding as HTTP/1.1.  In that case, it will be screwed by
persistent connections long before it ever sees an Upgrade.

The rules for handling 1xx extensions are defined by 100, not by 101.
101 required a change to the HTTP version to be introduced.  The same
would be true if we were to require specific handling of a future
status code, regardless of the 1xx-5xx class.  The obligation is on
the server that generates the status to verify that it is sending it
to a client capable of following the requirements.

IOW, if a client receives a 1xx status code that it doesn't understand,
then it can ignore it if and only if it didn't claim to understand that
status when it made the request.  If the client lies about its capabilities,
then things will get messy no matter what protocol is used.

> And there is no guarantee that a particular status code is transmitted end-to-end - 101 is certainly a per-hop mechanism, and in my experience 100 is commonly dropped by proxies.

101 is designed to be hop-by-hop.  100 and 102 are not.  What does that say
about 1xx codes in general?  Nothing.  Just like the other status codes.

A proxy that claims to be HTTP/1.1 and drops *any* status code when
forwarding to an HTTP/1.1 (or higher) client is not conforming to the
HTTP standard unless it is doing so explicitly to support a configured
workaround due to the client lying about its own version capabilities.

A non-conforming proxy will occasionally fail to interoperate with
conforming user agents and origin servers.  There is nothing we can do
about that other than to remove such non-conforming software.
Things break, with or without guarantees.

Our goal is to allow conforming implementations to do useful things,
which they do just fine in spite of the occasional glitch. Browsers
may well be concerned if 5% of networks have a broken proxy, since
it is rare for their customers to have the power to fix that proxy.
My customers usually have control over their own network.  The fact
that we can all use the same protocol to get things done is one of
the benefits of HTTP.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 18 Jul 2014 16:22:27 -0700

On Jul 18, 2014, at 10:19 AM, Roy T. Fielding wrote:

> a need for any more, and neither has anyone else.

Er, well, I should probably mention 103 Checkpoint

  https://code.google.com/p/gears/wiki/ResumableHttpRequestsProposal

though I will probably go back to forgetting it exists tomorrow.

....Roy

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 19 Jul 2014 10:48:29 +1000

On 19 July 2014 03:19, Roy T. Fielding <[email-masked]> wrote:

> browser usage of HTTP.  Get over it.
>

Well there is experience of 1xx codes usage in the working group.  As I
have pointed out, Jetty has a good implementation of 100 support, 101 and
also 102.    We see real usage of all the codes (ok not so much for 102,
but we'll send it if you want it).

We wish to continue supporting 100 semantic at least and our preferred way
to achieve that is by following rfc723x semantics as defined - but could
live with a new mechanism if it was well designed and motivated (but have
not seen such a proposal yet).      We also wish to support 101 and am very
keen to try an upgrade to waka (but can't find the detailed specification).

The option b) proposed is to define a document to deprecate all 1xx.   If
such a document could be produced and agreed to, then I would not weep on
the passing of 1xx - so long as it was widely supported and done for the
entire web.   However I am dubious that this group - or at least this
subset of the WG - has the authority or backing to propose such a wide
spread deprecation (ie deprecating the preferred access mode of little
sites like Amazon web services).

I admit to befuddlement at how we are tying ourselves in knots to support
streaming huge headers yet are prepared to discard a much more widely used
semantic.

I really don't understand the resistance to Julian's 1xx proposal is.  As
Roy says,  h1 implementations today have to handle 1xx at least to the
ignore it or fake it level.  Changing the transport for this semantic does
not add complexity, but making the semantic conditional on transport does.

cheers

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 20 Jul 2014 10:29:44 -0400

Greg,

On 18 Jul 2014, at 8:48 pm, Greg Wilkins <[email-masked]> wrote:

> The option b) proposed is to define a document to deprecate all 1xx.   If such a document could be produced and agreed to, then I would not weep on the passing of 1xx - so long as it was widely supported and done for the entire web.   However I am dubious that this group - or at least this subset of the WG - has the authority or backing to propose such a wide spread deprecation (ie deprecating the preferred access mode of little sites like Amazon web services).

(b) is to disallow *new* 1xx status codes, not deprecate the existing ones.

Cheers,

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

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 20 Jul 2014 14:59:10 -0400

Roy’s point below hasn’t been discussed in the context of HTTP/2 before IIRC; he’s right in that the nature of expect/continue in HTTP/1 is not just hop-by-hop. 

Given that, it sounds like we need to address this issue (e.g., using Julian’s patch), and also adjust our existing text about 100-continue (and perhaps even about 101).

That’s not to say that the WG can’t decide to deprecate further 1xx status codes in a separate document; just that HTTP/2 needs to carry this HTTP semantic (as per our charter).

I’m going to mark this as editor-ready soon. Any further comments? 

Thanks,

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 20 Jul 2014 21:13:53 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>Roy's point below hasn't been discussed in the context of HTTP/2 
>before IIRC; he's right in that the nature of expect/continue in 
>HTTP/1 is not just hop-by-hop. 

The problem is that you don't know what it is, and therefore it
is not particular attractive to use it outside controlled
environments.

100-Continue would become much more attractive to use if HTTP/2
made it end to end.

Obviously, we can not guarantee e2e if there are HTTP/1 nodes
involved, but I still think it would be an improvement to make
it e2e on pure H2 paths.

My preferred solution is a HEADERS bit which says "I'll send
the entity-body when you tell me to."

In order to not complicate things with new semantics we need to
explain, I would make the "tell me to" part a WINDOW_UPDATE from
the receiver on that stream.

If we go into the "send HEADERS with 100 :status" territory it will
make the protocol semantics and description much more complicated.

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 22 Jul 2014 11:19:33 +1000

On 21 July 2014 04:59, Mark Nottingham <[email-masked]> wrote:

> Roy’s point below hasn’t been discussed in the context of HTTP/2 before
> IIRC; he’s right in that the nature of expect/continue in HTTP/1 is not
> just hop-by-hop.
>
> Given that, it sounds like we need to address this issue (e.g., using
> Julian’s patch), and also adjust our existing text about 100-continue (and
> perhaps even about 101).
>

The commit that Martin has just made to close #535 says:
HTTP/2 removes support for the two 1xx series status codes defined in <xref
target="RFC7231" x:fmt="," x:rel="#status.1xx"/>): 100 (Continue), and 101
(Switching Protocols)

Is this a work in progress?    I took the meaning of Marks email was that
h2 would continue to support 100 and even maybe 101?

cheers

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 21 Jul 2014 19:28:38 -0700

> is not particular attractive to use it outside controlled

We have one protocol definition and it is based on interoperability
among conforming implementations.

> involved, but I still think it would be an improvement to make

100 is already end to end unless one of the intermediaries is not
conforming to HTTP/1.1, which is accounted for in the protocol.

> make the protocol semantics and description much more complicated.

It is far easier to just forward the 1xx status code.  After all,
the application is unlikely to know anything about h2/spdy, so it
will be waiting for the 100 Continue regardless.  The recipient's h2
protocol library will have to detect the hack and then translate
it into a fake 100 response for the application, which seems to be a
waste of effort.  In any case, framing hacks don't supplant the other
1xx status codes and are therefore not a solution to Julian's issue.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 21 Jul 2014 23:28:09 -0400

On 21 Jul 2014, at 9:19 pm, Greg Wilkins <[email-masked]> wrote:
> 
> Is this a work in progress?    I took the meaning of Marks email was that h2 would continue to support 100 and even maybe 101?

Yes; I chatted with Martin about this over dinner, we’ll get there.

Cheers,

---

From: Zhong Yu <[email-masked]>
Date: Mon, 21 Jul 2014 22:36:19 -0500

> 100-Continue would become much more attractive to use if HTTP/2

What is the end-to-end semantics though? As far as the application is
concerned, the request-response cycle has the same semantics whether
or not 100-continue is exchanged under the hood. Whether or not the
server can process the request without knowing the body does not rely
on the presence of 100-continue, and is not an interesting information
that has to be revealed, except for the purpose of optimization.

Zhong Yu
bayou.io

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 22 Jul 2014 14:03:32 +1000

On 22 July 2014 13:36, Zhong Yu <[email-masked]> wrote:

> or not 100-continue is exchanged under the hood.
>

The semantic that the client application is seeking is confirmation from
the origin server that it has inspected the headers and has consented for
the body to be sent.    Having an intermediary fake that consent does not
implement the same semantic, rather it elides the semantic with an assumed
positive response.

Whether or not the
> that has to be revealed, except for the purpose of optimization.

Firstly even if 100 is only an optimisation, we have gone to great lengths
with h2 to features that provide good quality of service for browser
clients.  So I do not think we can just remove something which has been
long implemented to address similar QoS concerns for non browser clients on
the basis that it is only an optimisation.

Besides, it is not purely an optimisation as it may be that on inspection
of the headers, the origin server determines that the request content needs
to be confidential and redirects the client to a secure port.  I'm not
saying this is a good or common way of implementing security, just that is
is a use-case I have been asked about about when we did not support 100
continues.

regards

---

From: Zhong Yu <[email-masked]>
Date: Tue, 22 Jul 2014 01:16:37 -0500

On Mon, Jul 21, 2014 at 11:03 PM, Greg Wilkins <[email-masked]> wrote:
> The semantic that the client application is seeking is confirmation from the
> origin server that it has inspected the headers and has consented for the
> body to be sent.

This is a new way of interpreting it, but it's probably not the
original intent, and it's not supported by the text of the spec. If a
server does not respond with 100, it doesn't mean the body is
forbidden to be sent; the client can always send the body regardless
of server response(s).

> Having an intermediary fake that consent does not
> clients.  So I do not think we can just remove something which has been long
> implemented to address similar QoS concerns for non browser clients on the
> basis that it is only an optimisation.

Agreed.

>
> Besides, it is not purely an optimisation as it may be that on inspection of
> the headers, the origin server determines that the request content needs to
> be confidential and redirects the client to a secure port.  I'm not saying
> this is a good or common way of implementing security, just that is is a
> use-case I have been asked about about when we did not support 100
> continues.
>
> regards
>
>
>
>
>
>
> --

---

From: Julian Reschke <[email-masked]>
Date: Tue, 22 Jul 2014 12:06:13 +0200

On 2014-07-22 08:16, Zhong Yu wrote:
> ....

Instead of sending the 100, the server can immediately send a 4xx error 
code.

Best regards, Julian

---

From: Michael Sweet <[email-masked]>
Date: Tue, 22 Jul 2014 08:32:53 -0400

and for example CUPS will first send a 101 (if necessary) to force TLS encryption of the connection and then a 401 if authorization is required.

On Jul 22, 2014, at 6:06 AM, Julian Reschke <[email-masked]> wrote:

> Instead of sending the 100, the server can immediately send a 4xx error code.
> 
> Best regards, Julian
>

---

From: Zhong Yu <[email-masked]>
Date: Tue, 22 Jul 2014 09:03:02 -0500

On Tue, Jul 22, 2014 at 5:06 AM, Julian Reschke <[email-masked]> wrote:
>>> the

The client is still allowed to send the request body in that case:

    http://tools.ietf.org/html/rfc7231#section-5.1.1

100-continue is a sufficient, but not necessary, precondition for the
request body. The mechanism allows opportunistic elision of the
request body, that's all.

If this is considered too weak, and H2 wants to strengthen the
semantics so that the client MUST wait for server approval before
sending the body, I'm all for it. But it is not the semantics of
100-continue in H1.

Zhong Yu
bayou.io

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 22 Jul 2014 10:33:31 -0400

Hi,
I wanted to weigh in on one specific use case for 1xx that has come up in 
CalDAV (RFC4791 - a WebDAV based calendaring and scheduling protocol).

Some CalDAV PUT/POST requests might take a long time to process (of the 
order of several minutes or more). Typically clients (in particular mobile 
clients) implement a client-side response timeout (often 2 minutes or so). 
If we know the request is likely to succeed obviously we want to keep the 
client connection alive past their timeout so that the response gets 
through. The original WebDAV spec (RFC2518) defined the 102 code for that 
purpose, but that code was removed (not deprecated) in the WebDAV update 
(RFC4918) because it was not being used.

Well now, some CalDAV servers are using 100-Continue as a keep-alive 
mechanism, and there are a couple of tweaks to that that would be handy 
(e.g., making use of a Prefer header that allows the client to communicate 
to the server what its client-side timeout is). Perhaps we should have 
adopted 102 for this purpose, but 100 seems to work well.

Some CalDAV implementations also make use of the "Expect: 100-continue" 
mechanism for handling uploads of large event attachments that servers 
often redirect from the "base URI" for attachment uploads.

So as far as HTTP/1.1 goes 100 (and possibly 102) are important for CalDAV. 
In terms of HTTP/2, I presume the PING frame can be used for "keep-alive". 
But I definitely want to see the equivalent of "Expect: 100-continue" 
available in some fashion (either the same as HTTP/1.1 or via some new 
feature specific to HTTP/2).

-- 
Cyrus Daboo

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Jul 2014 07:35:32 -0700

> sending the body, I'm all for it. But it is not the semantics of

I don't think that we need to change any semantics.  That invites
re-opening the 723x discussions, discussions that I know were lengthy.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 22 Jul 2014 16:46:53 +0200

On 2014-07-22 16:33, Cyrus Daboo wrote:
> Hi,
> I wanted to weigh in on one specific use case for 1xx that has come up
> in CalDAV (RFC4791 - a WebDAV based calendaring and scheduling protocol).
>
> order of several minutes or more). Typically clients (in particular
> mobile clients) implement a client-side response timeout (often 2
> minutes or so). If we know the request is likely to succeed obviously we
> want to keep the client connection alive past their timeout so that the
> response gets through. The original WebDAV spec (RFC2518) defined the
> 102 code for that purpose, but that code was removed (not deprecated) in
> the WebDAV update (RFC4918) because it was not being used.

I'd rephrase this as: it wasn't included in 4918 because we had zero 
implementations (mainly because most WebDAV servers people worked on 
back then were running on the Java servlet API, which didn't provide a 
way to send non-final responses). That means it continues to be defined 
in 2518 (as "proposed standard").

> (e.g., making use of a Prefer header that allows the client to
> communicate to the server what its client-side timeout is). Perhaps we
> should have adopted 102 for this purpose, but 100 seems to work well.
>

I'd say that using 100 for this is sort-of ok (it if serves the 
purpose), but it would be good to understand how the implementers that 
chose 100 over 102 came to the conclusion that it's better. It seems we 
have a education problem here; what's relevant for the applicability of 
status codes is how it appears in the IANA registry, after all.

> So as far as HTTP/1.1 goes 100 (and possibly 102) are important for
> CalDAV. In terms of HTTP/2, I presume the PING frame can be used for
> "keep-alive". But I definitely want to see the equivalent of "Expect:
> 100-continue" available in some fashion (either the same as HTTP/1.1 or
> via some new feature specific to HTTP/2).

Best regards, Julian

---

From: Zhong Yu <[email-masked]>
Date: Tue, 22 Jul 2014 10:23:48 -0500

> Well now, some CalDAV servers are using 100-Continue as a keep-alive

That seems a misuse of 100. Maybe 303 (one or more) is better.

> mechanism for handling uploads of large event attachments that servers often
> redirect from the "base URI" for attachment uploads.
>

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 22 Jul 2014 11:32:06 -0400

Hi Zhong,

> That seems a misuse of 100. Maybe 303 (one or more) is better.

I don't see how that can be applicable to this keep-alive case. If we 
wanted to have the client do a follow-up request to get the actual result 
of a time consuming request, then 202 Accepted would be the better way to 
do that.

-- 
Cyrus Daboo

---

From: Zhong Yu <[email-masked]>
Date: Tue, 22 Jul 2014 11:24:56 -0500

On Tue, Jul 22, 2014 at 10:32 AM, Cyrus Daboo <[email-masked]> wrote:
> I don't see how that can be applicable to this keep-alive case. If we wanted
> to have the client do a follow-up request to get the actual result of a time
> consuming request, then 202 Accepted would be the better way to do that.

There's no official way for a 202 response to indicate where to send a
follow-up request. My idea of using 303 for keep-alive is as the
following:

The client posts a task, the server immediately responds with

    HTTP/1.1 303 See Other
    Location: /result?id=1234&timeout=60&try=1

which triggers the client to send a GET request to retrieve the
result. For this request, the server blocks until either the result is
available, in which case it returns the final response, or the timeout
is reached, in which case it responds with another 303

    HTTP/1.1 303 See Other
    Location: /result?id=1234&timeout=60&try=2

and so on. The semantics is sanctioned by the spec. The behavior is
directed by the server, requiring no change in app protocol or client
software (assuming it handles 303s transparently).

Zhong Yu
bayou.io

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 23 Jul 2014 08:38:54 +1000

> forbidden to be sent; the client can always send the body regardless

Consent to send != permission to send.

Clients can always just send the body, but 100 continues allows them the
ask the application on the server if it is OK to send the body.      The
important part of this is that the question is asked of the application and
not of the transport.  It is not asking "can I send the body?",  it is
asking "should I send the body?".   The key difference here is that the
first question can be answered by a proxy, while the second question is
fundamentally an end to end question.

cheers

---

From: Zhong Yu <[email-masked]>
Date: Tue, 22 Jul 2014 18:13:18 -0500

On Tue, Jul 22, 2014 at 5:38 PM, Greg Wilkins <[email-masked]> wrote:
> Clients can always just send the body, but 100 continues allows them the ask
> the application on the server if it is OK to send the body.      The

The question is more like, "is it OK if I do *not* send the body?".
Only the origin server can give a "yes" answer to that, by sending a
final response code which in itself is end-to-end.

Even with the answer "yes, the body is not needed", the client can
send the body regardless, therefore the answer is advisory, and it
should have no impact on application semantics.

Zhong Yu
bayou.io

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 23 Jul 2014 09:16:11 +1000

> The question is more like, "is it OK if I do *not* send the body?".

OK I can see it that way.   But I think we are agreed that the point is the
question is asked of the origin server and not of an intermediary.

cheers