DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9488>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9488 HTTP/0.9 requests spoken on https port returns HTTP/1.0 response [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- OS/Version|Windows XP |All Platform|PC |All Summary|Simple "GET" requests (http |HTTP/0.9 requests spoken on |0.9) Behave incorrectly |https port returns HTTP/1.0 | |response Version|2.0.36 |HEAD ------- Additional Comments From [EMAIL PROTECTED] 2002-06-03 21:03 ------- Okay, so basically what's happening is that we depend upon OpenSSL to tell us when the data it got from the client resembles an HTTP request rather than an SSL handshake. The test looks like this: if ((n = SSL_accept(filter->pssl)) <= 0) { ... if (ERR_GET_REASON(ERR_peek_error()) == SSL_R_HTTP_REQUEST) { return HTTP_BAD_REQUEST; } ... } There's no distinction in there of whether it detected an 0.9 or an 1.x request, just that it wasn't SSL and it kinda looked like HTTP. The above condition triggers a hardcoded magic request GET /mod_ssl:error:HTTP-request HTTP/1.0 to be sent back up the input filter chain, which is obviously broken if the original request was in fact 0.9. So somehow we either need to get OpenSSL to give us back more information (like perhaps a copy of the data it errored out on) or we need to stash a copy of that data before OpenSSL processes it. Either way could be potentially messy... I'm not sure of the implementation details yet. --Cliff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
