On Thu, Nov 17, 2011 at 09:30:14AM -0500, Bill Speirs wrote: > Fair enough... I'm going to change my current JIRA ticket as what I > described in that ticket is not the proper way to "fix" the problem as > Robert pointed out. > > Oleg, any ideas on how to go about fixing this? Things will get > confusing fast as a 0.9, 1.0, or 1.1 request can come in, but the > developer can send back a 0.9, 1.0, or 1.1 request. I'll look into > it... >
I think the problem can be addressed by making ResponseConnControl protocol interceptor take the request version into accout and adding 'connection: close' header the response message if there is no explict connection persistence control (no 'connection' header present) in the HTTP/1.0 request. Oleg > Bill- > > On Thu, Nov 17, 2011 at 4:25 AM, Oleg Kalnichevski <[email protected]> wrote: > > On Wed, Nov 16, 2011 at 05:15:56PM -0500, Bill Speirs wrote: > >> On Nov 16, 2011 4:59 PM, "Oleg Kalnichevski" <[email protected]> wrote: > >> > I am pretty sure the server is expected to respond with a HTTP/1.0 > >> > message but cannot back it up with an excerpt from the spec. > >> > >> The only thing I found in the spec (http://www.ietf.org/rfc/rfc2068.txt) > >> was in section 19.7: an HTTP 1.1 server should respond to a client with a > >> message in the same major version number. > >> > >> > We can think about changing the API in such a way that an empty response > >> > object is created by the framework instead of leaving it up to > >> > individual handlers. > >> > > >> > Feel free to raise a change request in JIRA. > >> > >> I'll open an improvement request, because I don't think it's a bug. > >> However, I've actaully been bit by this twice now; fool me once... > >> > >> Bill- > > > > Hi Bill > > > > I was wrong. A HTTP/1.1 compliant server should respond with a HTTP/1.1 > > response to a HTTP/1.0 request but ensure that composition of the message > > is fully compatible with HTTP/1.0. > > > > So, there is a bug in the HttpCore protocol handling code. Please raise > > another JIRA for this defect. > > > > Oleg > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
