HttpClient/ContentExchange interprets response code 100 as end of message exchange

Michael,

I'm not sure that I like the modification to HttpParser to have a special case for the 100 response. The parser should parse entire HTTP messages and a 100 response is a valid HTTP message. It is HttpConnections job to deal with the state resulting from the parser, so it should be the one that handles 100's and I think that head of header and end of message events should still be generated.

Let me see if I can do that....

I've committed to the branch a variation that handles 1xx responses in much the same way as we handle 302s and 401s. Both of those use listeners to intercept the event handling and in those cases to retry the request. For 1xx we don't need to do the retry, but we do need to allow the parser to cycle and be reset.

Can you double check this, and look at how errors will be handled... specifically test for a 100 being sent followed by a timeout or a close.

cheers

Greg,

My original fix was based on my discussion with Simone about this issue, and was no doubt a bit hacky. I completely agree that your solution is more efficient and elegant. It will also be much easier to modify to enable the ProxyServlet to pass the CONTINUE 100 response back to the client in the event it was the client and not the proxy that requested it.

I think we also need to have the NonFinalResponseListerner call the original event listener when it receives onResponseHeader and onResponseHeaderComplete event notifications for CONTINUE 100 response in order for the client to be able to process the optional headers that could be included with the preliminary response.

I'm also going to look into the error handling later today as you requested.

-Michael

I've added more listener proxy calls from NonFinalResponseListener to the original listener to account for various situations that could potentially occur. I also added three
more tests to the harness that check for correct behavior of the client if CONTINUE 100 is expected but not sent, an error response is sent, or a timeout occurs.

It is important to note that all above mentioned changes are going to be implemented in the Jetty 7.5.x release.

According to RFC 2616, section 10, "The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response." The language of the RFC means that it is not mandatory for the client to continue with the request when CONTINUE 100 response is received.

Because Jetty 6.x is currently in maintenance mode, we do not expect to make this change in this version. Please vote for this ticket if you would want to have it fixed in a maintenance release of Jetty 6.1.x that is tentatively planned for November, 2011 timeframe.

-Michael