Expect/Continue and Removing 1xx Final Status codes from HTTP/2

At last week's Interim in Seattle, we discussed how we'll handle Expect/Continue in HTTP/2.0.


The plan so far has been to NOT accommodate Expect/Continue on the wire, instead requiring software that receives an Expect header before an HTTP/2.0 hop to synthesise a 100 Continue response.

For example, a 1.1 -> 2.0 intermediary would immediately send a 100 Continue response and forward the request.

Likewise, a 2.0 client API that receives "Expect: 100-continue" in a request header block would synthesise a 100 Continue response and forward the request.

The thinking behind this is that HTTP/2 provides tools that allow the server to avoid wasting bandwidth without sacrificing the connection if it wants to reject the request. To wit, it can send a final response and then reset the stream. Likewise, the client can flow control the tentative request for a RT before utilising full bandwidth, in anticipation of a potential final response rejecting the request.

In addition, we discussed 1xx (non-final) status codes more generally.


The feeling in the room in Seattle AIUI was that non-final status codes are a signalling mechanism that is no longer necessary in HTTP/2, since the framing layer can do a better job at these tasks. As such, we do not plan to accommodate non-final status codes (1xx) in HTTP/2.0, but instead will give advice about how they can be handled by intermediaries doing transitions between 1.x and 2.x (with one example above). 

I have action items to write up detailed proposals for both of these issues. Before that happens, we wanted to make sure a wider audience was aware of this and comfortable with it, since this is a fairly big change. What do people think?


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

Received on Tuesday, 15 October 2013 00:43:58 UTC