On 7 April 2010 17:16, Matt <[email protected]> wrote: > Hi Willy, > > That trace is from curl using --verbose, looks like one empty line after > Expect: 100-continue > > Here using --trace-ascii it definitely looks like an empty line after > > 00b7: content-type:application/xml > 00d9: Content-Length: 0 > 00ec: Expect: 100-continue > 0102: > == Info: HTTP 1.0, assume close after body > <= Recv header, 26 bytes (0x1a) > 0000: HTTP/1.0 502 Bad Gateway > <= Recv header, 25 bytes (0x19) > 0000: Cache-Control: no-cache > <= Recv header, 19 bytes (0x13) > 0000: Connection: close > <= Recv header, 25 bytes (0x19) > 0000: Content-Type: text/html > <= Recv header, 2 bytes (0x2) > 0000: > <= Recv data, 107 bytes (0x6b) > 0000: <html><body><h1>502 Bad Gateway</h1>.The server returned an inva > 0040: lid or incomplete response..</body></html>. > <html><body><h1>502 Bad Gateway</h1> > The server returned an invalid or incomplete response. > </body></html> > == Info: Closing connection #0 > > I'll try the latest snapshot now. > > Thanks, > > Matt > > On 7 April 2010 13:44, Willy Tarreau <[email protected]> wrote: > >> Hi Matt, >> >> On Wed, Apr 07, 2010 at 11:10:58AM +0100, Matt wrote: >> > When using curl :- >> > * Server auth using Digest with user 'su' >> > > PUT ............. HTTP/1.1 >> > > User-Agent: curl/7.19.5 (i486-pc-linux-gnu) libcurl/7.19.5 >> OpenSSL/0.9.8g >> > zlib/1.2.3.3 libidn/1.15 >> > > Host: .......... >> > > Accept: */* >> > > content-type:application/xml >> > > Content-Length: 0 >> > > Expect: 100-continue >> > > >> > < HTTP/1.1 100 Continue >> > * HTTP 1.0, assume close after body >> > < HTTP/1.0 502 Bad Gateway >> > < Cache-Control: no-cache >> > < Connection: close >> > < Content-Type: text/html >> (...) >> >> Where was this trace caught ? Are you sure there was no empty line after >> the "HTTP/1.1 100 Continue" ? That would be a protocol error, but maybe >> it's just an interpretation of the tool used to dump the headers. >> >> > The Jetty server throws an exception :- >> > HTTP/1.1 PUT >> > Request URL: http://.......... >> > User-Agent: curl/7.19.5 (i486-pc-linux-gnu) libcurl/7.19.5 >> OpenSSL/0.9.8g >> > zlib/1.2.3.3 libidn/1.15 >> > Host: ............ >> > Accept: */* >> > Content-Type: application/xml >> > Content-Length: 0 >> > Expect: 100-continue >> > X-Forwarded-For: ........... >> > Connection: close >> > Querystring: null >> > -ERROR Authenticator Authenticator caught IO Error when >> trying >> > to authenticate user! >> > org.mortbay.jetty.EofException >> > org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:760) >> > >> org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerator.java:565) >> > org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:904) >> > >> org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:633) >> > >> org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:586) >> > >> org.mortbay.jetty.security.DigestAuthenticator.authenticate(DigestAuthenticator.java:131) >> > ........... >> > Caused by: java.nio.channels.ClosedChannelException >> > ........... >> > >> > HA Proxy debug:- >> > accept(0007)=0008 from [...........:49194] >> > clireq[0008:ffff]: PUT ........... HTTP/1.1 >> > clihdr[0008:ffff]: User-Agent: curl/7.19.5 (i486-pc-linux-gnu) >> > libcurl/7.19.5 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15 >> > clihdr[0008:ffff]: Host: ................ >> > clihdr[0008:ffff]: Accept: */* >> > clihdr[0008:ffff]: content-type:application/xml >> > clihdr[0008:ffff]: Content-Length: 0 >> > clihdr[0008:ffff]: Expect: 100-continue >> > srvrep[0008:0009]: HTTP/1.1 100 Continue >> > srvcls[0008:0009] >> > clicls[0008:0009] >> > closed[0008:0009] >> > >> > Making sure that both httpclose and http-server-close are absent causes >> the >> > requests to work. >> >> This would make me think about another funny behaviour in the server, >> related to "Connection: close". Could you try latest 1.4 snapshot and >> add "option http-pretend-keepalive" ? It is possible that the server >> disables handling of the 100-continue when it sees a close (which is >> not related at all, but since this is the only difference, we can think >> about another home-made HTTP implementation). >> >> Regards, >> Willy >> >> Latest snapshot on 1.4.3
- option http-pretend-keepalive - works - option http-pretend-keepalive and httpclose - same behaviour as before, errors - option http-server-close - same behaviour as before, errors - option http-server-close and http-pretend-keepalive - works What exactly does pretend-keepalive do? Thanks, Matt
