https://issues.apache.org/bugzilla/show_bug.cgi?id=47087
--- Comment #15 from Sven Mueller <[email protected]> 2009-12-16 07:07:48 UTC --- (In reply to comment #13) > (In reply to comment #12) > > > Anyhow, as far as I understood from the discussion, this patch disables > > keepalive for any response but "100 Continue", which means the connections > > are > > closed after the final response. Unfortunately, this would cause troubles > > here, > > as we found out. Some of the clients simply don't reconnect when they asked > > for > > a keep-alive session. If they get a disconnect with the non-100 response, > > they > > seem to report an error. > > Closing the connection is always at least an option under HTTP, and any client > that can't cope is broken. Bearing in mind that non-100 responses are > commonly > genuine errors and should indeed be reported as such, are you saying you get > an > error in the case of a non-error response? Well, yes. I agree that the clients are broken. But as those are paying customers (and their client used to work with Apache 2.0), I'm not exactly in a position to force them to immediately fix/update their clients. What we saw was this sequence: Client sends request with 100-continue expectation (note: It actually sends the full request, headers and body, as far as I could tell from tcpdump/wireshark protocols), unauthenticated. Server answers with "authentication required", and gets to see body of request (which actually is a single line XML thingy in our case) with the header of the authenticated request appended to it (ie. "<xml>...</xml>PUT ...." or something similar). Trouble is the broken clients which won't retry. If we use nokeepalive on the clients, some correctly reopen the connection, sending the second request cleanly. Others however won't do so, so we needed to ignore their 100-continue expectation, causing the http daemon to read the full initial request before sending the authentication required response, after that the client successfully sent an authenticated request. So for us, the update committed as a result of this bug report doesn't actually fix all client problems we had (but most of them, like 75%). To work around the problems with the rest of our customers clients, the ignore-continue patch I proposed in the other bug report (https://issues.apache.org/bugzilla/show_bug.cgi?id=46709) would still be needed. <rant>Damn .Net, why can't it just do the correct things by default? Oh, I forgot it is a microsoft product, so that probably explains it</rant> regards, Sven -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
