So what are you suggesting that the appropriate fix should be? Even though the protocol.c patch was bogus, it sounds like might have exposed something else. In fact I am still not seeing where the problem is. The protocol.c patch was just allowing a bad response to happen that should never have happened in the first place. It seems like the appropriate OPTIONS response should include C-L:0. Anything else that actually has content would also contain the appropriate C-L: header.
Brad >>> [EMAIL PROTECTED] Tuesday, December 07, 2004 12:51:15 PM >>> On Tue, Dec 07, 2004 at 11:01:13AM -0700, Brad Nicholes wrote: > >I tested the TLS upgrade stuff last week and it failed because the > >zero-length chunk to terminate the OPTIONS response was not sent > through > >the mod_ssl output filter; is that the same problem you see? > > I don't think so. I can make everything work again by simply allowing > the "Content-Length: 0" header to be sent through. I'm not sure what > impact that header has on the rest of mod_ssl. Obviously by removing > it, it causes mod_ssl to *not* do something it was suppose to. My guess > is that if the zero-length chunk that terminates the OPTIONS response is > not being sent, it is probably a result of mod_ssl not seeing a > content-length header. I think we are seeing the same problem. Before, a zero-length OPTIONS response would be sent with t-e: chunked and a single zero-terminator-chunk. The "0\r\n\r\n" packet was being sent unencrypted and breaking the SSL connection. After you reverted the protocol.c change, a zero-length OPTIONS response is sent with C-L: 0 and hence terminates after the headers. Subsequent requests on the connection get the right filter stack. So you have successfully hidden the mod_ssl bug for upgrades with zero-length responses. The fact that mod_ssl (incorrectly) refuses to upgrade anything other than an OPTIONS request makes the bug less obvious since OPTIONS responses are rarely anything but zero-length, but I'll fix that. For an upgrade on GET the strace now looks like: send(3, "GET / HTTP/1.1\r\nHost"..., 173, 0) = 173 recv(3, "HTTP/1.1 101 Switchi"..., 4096, 0) = 85 read(4, "*J\204\17\342g l\327U\323/\271"..., 32) = 32 write(3, "\200|\1\3\1\0c\0\0\0\20\0\0009"..., 126) = 126 <SSL negotiation and response headers> read(3, "\26\3\1\0000", 5) = 5 read(3, "a\20\363\37{\372\347\205\350\36"..., 48) = 48 read(3, "<html", 5) = 5 ^^^^^ uh-oh! > BTW, what are you using to test TLS Upgrade with? A hacked up version of neon.