Re: issue with using digest with jetty backends

From: Matt <mattmoran76#gmail.com>
Date: Wed, 7 Apr 2010 17:42:24 +0100


On 7 April 2010 17:16, Matt <mattmoran76#gmail.com> 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 <w#1wt.eu> 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

What exactly does pretend-keepalive do?

Thanks,

Matt Received on 2010/04/07 18:42

This archive was generated by hypermail 2.2.0 : 2010/04/07 18:45 CEST