- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 14 Oct 2013 17:43:30 -0700
- To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
At last week's Interim in Seattle, we discussed how we'll handle Expect/Continue in HTTP/2.0. https://github.com/http2/http2-spec/issues/18 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. https://github.com/http2/http2-spec/issues/264 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? Regards, -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 15 October 2013 00:43:58 UTC