Hi guys, I'm very sorry for the late response, just trying to catch up with the long mail queue as I'm having less time these days.
On Mon, Aug 25, 2014 at 06:39:22PM +0200, Lukas Tribus wrote: > Hi Ryan, > > > > I apologize, but I am not sure the usual procedure regarding changes. > > What is the next step? Should I put together a change that simply looks > > for status codes less than 200, but that is not 101? Or did we need > > more discussion? > > I would like to hear Willy's opinion about whether to remove the condition > entirly (since "100 continue" behavior will not change) or if we should just > treat 101 as an exception to that condition. > > Personally, I'm in favor of removing that condition entirely, because > I believe there is no real benefit here and by removing it we simplify the > code. In fact, 101 is indeed an exception. 1xx responses are informational and can appear multiple times before a final response. 100 is a good example of this where any intermediary can emit one, resulting in multiple responses reaching the client. 102 (progress) is even more obvious. User-agents are supposed to ignore any 1xx they're not interested in, and to only process the final response. So whatever we put there in headers is likely to be ignored. That's why header processing is skipped for 1xx. And 100 must not contain any header! But 101 started to be *really* used by WebSocket (and now by HTTP/2). It works differently, despite belonging to the 1xx family and having to follow the rule of "if you don't know it, handle it just like 100". Strictly speaking, it *is* an interim response as it informs that the server is willing to upgrade and to provide a response using another protocol. However we also know it is the last HTTP/1.1 response that will be received on this connection, which makes a difference with other 1xx, hence why it cannot really be mapped to 100. I must say I have been hesitating about processing headers for 101 or not, but since WebSocket clients were not supposed to learn cookies during a WebSocket upgrade (I remember that's a discussion we had in the WS working group, that led to nowhere), and some early implementations were quite picky about the response's format (due to the original byte-encoded WS response in the very early versions of the desing), it appeared that doing so would cause more harm than anything else. There was also something else : with the Connection: close header that was added to responses by older haproxy versions (1.3 and earlier), some clients were unhappy because they were not seeing exactly the "Connection: upgrade" field they were expecting. Since 1.4 we don't have this issue and we already made exceptions for protecting Connection: in 101. Now that WS has reached Standard Tracks, we don't care about previous implementations and we could rewrite headers, so I think that doing it for 101 should not be a big issue. However I do have real doubts about the usefulness of doing so, considering that I used to observe that clients didn't learn cookies in response to 101 in the past. I think that experimenting with (txn->status < 200 && txn->status != 101) everywhere we currently have a test for < 200 should be a good start. I'd rather do this in 1.6-dev first and observe for some time before backporting to 1.5, and why not, 1.4. Regards, Willy
