Subject: #535: No 1xx Status Codes

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Jun 2014 17:56:57 +1000

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

This seems like a re-opening of <https://github.com/http2/http2-spec/issues/264>. We discussed it a fair amount in the Seattle interim, and there was pretty strong support in the room for getting rid of 1xx status, especially since they're poorly supported in implementations, almost non-existant in APIs, and often don't survive hop-to-hop. 

Julian, anything to add? I'm inclined to close this as a duplicate unless there's significant new information...

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 Jun 2014 11:20:24 +0200

> Julian, anything to add? I'm inclined to close this as a duplicate unless there's significant new information...

I still fail to see a compelling reason to remove them.

Why do we keep trailers, but not 1xx? I'd like to understand how we draw 
the line.

Best regards, Julian

---

From: <[email-masked]>
Date: Fri, 27 Jun 2014 09:44:33 +0000

On Friday,27 June 2014 11:20, [email-masked] wrote:
> Why do we keep trailers, but not 1xx? I'd like to understand how we draw the line.

I'm confused on that point myself.  According to Martin the calculus is very straightforward.  In which case 1xx should be included and transfer codings.

On Friday,27 June 2014 04:22, [email-masked] wrote:
> Can HTTP do X -> HTTP/2 MUST do X.

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

---

From: Michael Sweet <[email-masked]>
Date: Fri, 27 Jun 2014 12:58:55 -0400

Mark,

I agree this is a duplicate and think the current wording in the spec about the Expect header and 1xx status codes is sufficient to explain how gateways must behave.

The primary reasons for using "Expect: 100-continue" for HTTP/1.1 are addressed by HTTP/2's framing and multiplexing - a Client can safely send a request and have that stream terminated early without the loss of a connection, using the same logic for POSTs to avoid sending sensitive info before authentication/upgrade (send request headers and wait a second or two for a response before continuing).

Trailers (mentioned in the linked issue) are a separate issue and are required for HTTP Digest authentication with message integrity checking, among other things.  You can't satisfy that requirement with framing and multiplexing.

> Julian, anything to add? I'm inclined to close this as a duplicate unless there's significant new information...

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Michael Sweet <[email-masked]>
Date: Fri, 27 Jun 2014 13:27:46 -0400

Julian,

> Why do we keep trailers, but not 1xx? I'd like to understand how we draw the line.

Since trailers are used to communicate header fields that depend on the message body, we need to keep those because otherwise the sender would need to know the entire contents of the message body before sending them in the request...

Status code 100 is really only useful in preventing a connection from being torn down due to an exception for a POST or PUT request, and HTTP/2 streams basically provide this functionality all the time.

Status code 101 is effectively replaced/supported by the HTTP/2 extension mechanism.

Status code 102 seems only useful as a way to let the client know that the server is still alive - perhaps PING frames could be used from the Client to verify that the server is still alive?  In any case, the whole "connection timeout" verbiage in RFC 2518 probably doesn't apply to HTTP/2 which expects clients to reuse existing connections rather than opening multiple connections.

Perhaps the thing to do here is just document what to do with 101 and 102 (the spec already talks about 100).

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 Jun 2014 19:45:35 +0200

> Since trailers are used to communicate header fields that depend on the message body, we need to keep those because otherwise the sender would need to know the entire contents of the message body b…

So are they used in practice? Not when communicating with browsers, right?

> Perhaps the thing to do here is just document what to do with 101 and 102 (the spec already talks about 100).

I'm really not interested a lot in 100/101/102 but in the *class* of 
error codes that's being taken away from us.

Best regards, Julian

---

From: Michael Sweet <[email-masked]>
Date: Fri, 27 Jun 2014 14:17:12 -0400

Julian,

On Jun 27, 2014, at 1:45 PM, Julian Reschke <[email-masked]> wrote:
>>> ...

I don't know of any browsers that support trailers or HTTP Digest auth-int at the moment, no.

> I'm really not interested a lot in 100/101/102 but in the *class* of error codes that's being taken away from us.

I'm not sure what we're losing: in the 17 years since HTTP/1.1 was published we've had a total of three 1xx status codes (and the most recent - 102 - was published as part of WEBDAV in 1999).  Acknowledging that the number of registered status codes is a poor measure of how useful the 1xx status codes are, what sort of use cases are you thinking of?

100 and 101 are clearly supported through specific HTTP/2 mechanisms.

102 *might* still have some use as an intermediate progress reporting state, even for HTTP/2, but the general keep-alive behavior should be unnecessary for HTTP/2.

What about just prohibiting 100 and 101 (with documentation on their replacements) and making some general statement about other 1xx status codes?