You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2006/01/26 23:18:27 UTC
Re: Antwort: Re: Antwort: Re: HttpClient 3.0 rc4 hangs at the end
of chunked response
On Thu, 2006-01-26 at 22:57 +0100, Balazs Szuecs wrote:
> Hello,
>
> I checked the situation again, and now I experimented with HTTP versions.
>
> Using HTTP 1.1
>
> POST /disp HTTP/1.1
> Content-Type: application/octet-stream
> User-Agent: Java1.3.1_13
> Cookie: JSESSIONID=884FB53DDEDAB25A65FF33D6A53AB163.1;
> Host: bnic1s2j1:8009
> Content-Length: 950
>
> HTTP/1.1 200 OK
> Pragma: no-cache
> Content-Type: text/xml; charset=utf-8
> Transfer-Encoding: chunked
> Date: Wed, 25 Jan 2006 16:56:10 GMT
> Server: Apache Coyote/1.0
>
> from the view of my application it is a single HttpClient.executeMethod()
> call. The servlet returns the response, which is also wire-logged, then
> the client actually hangs, waiting for (another?) status line, (see my
> previous mail) without having returned from executeMethod()
>
Pardon me, but I doubt this observation is correct. HttpClient *never*
reads response content inside HttpClient#executeMethod() for 2xx type of
responses. This method *always* returns right after having received a
valid response header. The exception is made for redirects (3xx status
codes), where the response content can be automatically consumed.
> I tried the same call changing the protocol to HTTP 1.0
> (postMethod.getParams().setVersion( HttpVersion.HTTP_1_0 );):
>
> POST /disp HTTP/1.0
> Content-Type: application/octet-stream
> User-Agent: Java1.3.1_13
> Cookie: JSESSIONID=2F33008420F8528D3335D6FCD0CA6258.0;
> Host: bnic1s1j1:8009
> Content-Length: 950
>
> HTTP/1.1 200 OK
> Pragma: no-cache
> Content-Type: text/xml; charset=utf-8
> Date: Thu, 26 Jan 2006 20:54:31 GMT
> Server: Apache Coyote/1.0
> Connection: close
>
> It is interesting, that the server (Tomcat 4.1.27) responds with HTTP 1.1,
> even if the request was 1.0. But more important is the fact, that the
> server terminates the connection (Connection: close), telling the client,
> that this is the end of response. In this case everything works fine, the
> client does not block any more.
>
> Now I'm considering to use HTTP 1.0 instead of HTTP 1.1, but I have
> worries about connection pooling (MultithreadedConnectionManager), which
> maybe has no sense with HTTP 1.0, where connections are closed after each
> http call. Is it right?
>
Not necessarily. Just make sure you explicitly request the connection to
be kept alive by sending "Connection: Keep-Alive" header with every
request.
> I've found some newsgroup postings which suggest that this behaviour is a
> Tomcat bug, but I'm not sure about it.
>
I doubt this is the case. I used to test HttpClient extensively against Tomcat 4.1.x and have never observed this behavior.
Oleg
>
> What is your opinion?
>
> thank you!
>
> Balazs
>
>
>
>
>
> Oleg Kalnichevski <ol...@apache.org>
> 20.01.2006 17:10
> Bitte antworten an
> "HttpClient User Discussion" <ht...@jakarta.apache.org>
>
>
> An
> HttpClient User Discussion <ht...@jakarta.apache.org>
> Kopie
>
> Thema
> Re: Antwort: Re: HttpClient 3.0 rc4 hangs at the end of chunked response
>
>
>
>
>
>
> Balazs Szuecs wrote:
> > hi,
> >
> > I checked my code, and after wire-logging the entire response content it
>
> > surely still hangs in socketRead, here is the stacktrace of it:
> >
> > SocketInputStream.socketRead(byte[], int, int) line: not available
> [native
> > method]
> ...
> > PostMethod(HttpMethodBase).readStatusLine(HttpState, HttpConnection)
> line:
> > 1832
> ...
> Pardon me, but HttpClient is blocked awaiting a status line (see above)
> of an HTTP response. This has *nothing* to do with the chunk encoding.
>
> Please double-check your code once again
>
> Oleg
>
> > PostMethod(HttpMethodBase).readResponse(HttpState, HttpConnection) line:
>
> > 1590
> > PostMethod(HttpMethodBase).execute(HttpState, HttpConnection) line: 995
> > HttpMethodDirector.executeWithRetry(HttpMethod) line: 395
> > HttpMethodDirector.executeMethod(HttpMethod) line: 170
> > HttpClient.executeMethod(HostConfiguration, HttpMethod, HttpState) line:
>
> > 396
> > HttpClient.executeMethod(HttpMethod) line: 324
> >
> > I use HTTP1.1, allow no redirects, and I have a
> > MultithreadedConnectionManager (pool) behind the client. As far as I
> know,
> > two empty lines after a chunk should terminate the reading, but
> > unfortunately it does not happen. Other requests to the same server
> which
> > don't use chunk encoding but specify a content-length response header
> work
> > fine with the same code.
> >
> > Btw. shouldn't ChunkedInputStream occur somewhere in the trace above?
> >
> > best regards
> > Balazs
> >
> >
> >
> >
> >
> > Oleg Kalnichevski <ol...@apache.org>
> > 20.01.2006 14:26
> > Bitte antworten an
> > "HttpClient User Discussion" <ht...@jakarta.apache.org>
> >
> >
> > An
> > HttpClient User Discussion <ht...@jakarta.apache.org>
> > Kopie
> >
> > Thema
> > Re: HttpClient 3.0 rc4 hangs at the end of chunked response
> >
> >
> >
> >
> >
> >
> > Balazs Szuecs wrote:
> >
> >>Hello,
> >>
> >>I use HttpClient 3.0 rc4 and I'm experiencing a problem with chunked
> >>transfer encoding. The client connects to a Tomcat 4.1 servlet, which
> >>returns data with chunked encoding. I can see in the wire log, that the
> >>entire data has been transferred, even the two blank lines as the end of
>
> >
> > a
> >
> >>chunked response message. However, the client hangs at the end of the
> >>response message, and waits forever (until read timeout) for more
> >
> > response
> >
> >>bytes to come! How do I instruct HttpClient to handle chunked responses
> >>correctly? (see full wire log below)
> >>
> >>thank you very much!
> >>Balazs
> >>
> >
> >
> > HttpClient is not known to have any issues with the chunk-encoding. I
> > regularly test HttpClient and HttpComponents against Tomcat.
> >
> > You do not have to do anything special to make HttpClient handle
> > chunk-encoding. The transfer encoding processing is absolutely
> > transparent to the caller.
> >
> > I suggest you double-check your code.
> >
> > Oleg
> >
> >
> >
> >>20060119 17:00:52,354 httpclient.wire.header DEBUG>> "POST /disp
> >>HTTP/1.1[\r][\n]"
> >>20060119 17:00:52,373 httpclient.wire.header DEBUG>> "Content-Type:
> >>application/octet-stream[\r][\n]"
> >>20060119 17:00:52,384 httpclient.wire.header DEBUG>> "User-Agent:
> >>Java1.3.1_13[\r][\n]"
> >>20060119 17:00:52,396 httpclient.wire.header DEBUG>> "Cookie:
> >>JSESSIONID=84F2963C9FED08E7AF7896A125AB6DD7.0;[\r][\n]"
> >>20060119 17:00:52,408 httpclient.wire.header DEBUG>> "Host:
> >>bnic1s1j1:8009[\r][\n]"
> >>20060119 17:00:52,417 httpclient.wire.header DEBUG>> "Content-Length:
> >>950[\r][\n]"
> >>20060119 17:00:52,426 httpclient.wire.header DEBUG>> "[\r][\n]"
> >>20060119 17:00:52,444 httpclient.wire.content DEBUG>>
> >>
> >
> >
> "[0xac][0xed][0x0][0x5]sr[0x0]-infinity.security.connector.RequestDataIntern[0x1a][0x81][0x83]*[0x84]5z{[0x2][0x0][0xc]J[0x0][0xf]ifModifiedSinceJ[0x0][0xb]requestHashL[0x0][0x12]originalRemoteAddrt[0x0][0x12]Ljava/lang/String;L[0x0][0x8]paramMapt[0x0][0x15]Ljava/util/Hashtable;L[0x0][0x8]pathInfoq[0x0]~[0x0][0x1]L[0x0][0xb]queryStringq[0x0]~[0x0][0x1]L[0x0][\r]requestMethodq[0x0]~[0x0][0x1]L[0x0][\n]"
> >
> >>20060119 17:00:52,474 httpclient.wire.content DEBUG>>
> >>
> >
> >
> "requestURIq[0x0]~[0x0][0x1]L[0x0][0xb]serviceNameq[0x0]~[0x0][0x1]L[0x0][0x10]serviceParametert[0x0][0x12]Ljava/lang/Object;L[0x0][0xb]servletPathq[0x0]~[0x0][0x1]L[0x0][0xb]uploadFilest[0x0][0x10]Ljava/util/List;xp[0x0][0x0][0x0][0x0][0x0][0x0][0x0][0x0][0x0][0x0][0x0][0x0][0x0][0x89][0xec]3t[0x0][\r]162.25.212.20sr[0x0][0x13]java.util.Hashtable[0x13][0xbb][0xf]%!J[0xe4][0xb8][0x3][0x0][0x2]F[0x0][\n]"
> >
> >>20060119 17:00:52,501 httpclient.wire.content DEBUG>>
> >>
> >
> >
> "loadFactorI[0x0][0x9]thresholdxp?@[0x0][0x0][0x0][0x0][0x0][0x8]w[0x8][0x0][0x0][0x0][0xb][0x0][0x0][0x0][0x6]t[0x0][0x9]verfuegerur[0x0][0x13][Ljava.lang.String;[0xad][0xd2]V[0xe7][0xe9][0x1d]{G[0x2][0x0][0x0]xp[0x0][0x0][0x0][0x1]t[0x0][0x10]80FBC87C27DC70C7t[0x0][0x5]firmauq[0x0]~[0x0][\n]"
> >
> >>20060119 17:00:52,519 httpclient.wire.content DEBUG>>
> >>
> >
> >
> "[0x0][0x0][0x0][0x1]t[0x0][0x10]9A18E661F175F551t[0x0][0x7]partneruq[0x0]~[0x0][\n]"
> >
> >>20060119 17:00:52,530 httpclient.wire.content DEBUG>>
> >>
> >
> >
> "[0x0][0x0][0x0][0x1]t[0x0][0xb]smartstreamt[0x0][0xb]verfuegerBNuq[0x0]~[0x0][\n]"
> >
> >>20060119 17:00:52,542 httpclient.wire.content DEBUG>>
> >>
> >
> >
> "[0x0][0x0][0x0][0x1]t[0x0]0A1CEF212EA42DDF67F585633ED81BB4E0B042FFDA43BFCB3t[0x0][0x7]encodeduq[0x0]~[0x0][\n]"
> >
> >>20060119 17:00:52,555 httpclient.wire.content DEBUG>>
> >>
> >
> >
> "[0x0][0x0][0x0][0x1]t[0x0]@R2zNYaz1QT+lHCvsil9jhkWvttVWnjnFtDVGzlQCjuYCKWYCKWUVdKaA/CkvRVvpt[0x0][0x7]firmaBNuq[0x0]~[0x0][\n]"
> >
> >>20060119 17:00:52,571 httpclient.wire.content DEBUG>>
> >>
> >
> >
> "[0x0][0x0][0x0][0x1]t[0x0]0ADADFA6FCBECCDCBE7748A45A47DE6B80B99329C3ABE0E5Cxppt[0x0][0x4]POSTt[0x0][0x1c]/TradeConnectUserDataServlett[0x0][0x1b]TradeConnectUserDataServicept[0x0][0x1c]/TradeConnectUserDataServletp"
> >
> >>20060119 17:00:52,613 httpclient.wire.header DEBUG<< "HTTP/1.1 200
> >>OK[\r][\n]"
> >>20060119 17:00:52,632 httpclient.wire.header DEBUG<< "Pragma:
> >>no-cache[\r][\n]"
> >>20060119 17:00:52,642 httpclient.wire.header DEBUG<< "Content-Type:
> >>text/xml; charset=utf-8[\r][\n]"
> >>20060119 17:00:52,652 httpclient.wire.header DEBUG<< "Transfer-Encoding:
>
> >
> >
> >>chunked[\r][\n]"
> >>20060119 17:00:52,662 httpclient.wire.header DEBUG<< "Date: Thu, 19 Jan
> >>2006 16:00:52 GMT[\r][\n]"
> >>2000119 17:00:52,672 httpclient.wire.header DEBUG<< "Server: Apache
> >>Coyote/1.0[\r][\n]"
> >>20060119 17:00:53,724 httpclient.wire.content DEBUG<< "4"
> >>20060119 17:00:53,731 httpclient.wire.content DEBUG<< "d"
> >>20060119 17:00:53,738 httpclient.wire.content DEBUG<< "9"
> >>20060119 17:00:53,744 httpclient.wire.content DEBUG<< "[\r]"
> >>20060119 17:00:53,751 httpclient.wire.content DEBUG<< "[\n]"
> >>20060119 17:00:53,759 httpclient.wire.content DEBUG<< "<?xml
> >
> > version="1.0"
> >
> >>encoding="utf-8"?>[\n]"
> >>20060119 17:00:53,801 httpclient.wire.content DEBUG<<
> >>"<Userdata><Status>ok</Status><Statusmessage>Userdata is
> >>
> >
> >
> OK!</Statusmessage><BNID>7889180711580351471</BNID><OLAVID>01381317</OLAVID><FirmBNID>-3943745741496866276</FirmBNID><FirmOLAVID>50907897</FirmOLAVID><FirstName>Walter</FirstName><LastName>K[0xc3][0xb6]ck</LastName><HlpUil>DE</HlpUil><ApplicationUil>DE</ApplicationUil><Title></Title><Salutation>Sehr
>
> >
> >
> >>geehrter Herr
> >>Kmzlr.!</Salutation><Street>B[0xc3][0xa4]ckenbr[0xc3][0xbc]nnlgasse
> >>
> >
> >
> 7b</Street><PostalCode>1180</PostalCode><City>Wien</City><Country>AT</Country><Email></Email><PhoneNumber></PhoneNumber><MobileNumber></MobileNumber><FaxNumber></FaxNumber><Account><AccountNumberOLAV>00677124000</AccountNumberOLAV><AccountCurrency>EUR</AccountCurrency><AccountType>KK</AccountType><AccountProductNumber>00040</AccountProductNumber><AccountRole>ZBE</AccountRole><AccountBLZ>12000</AccountBLZ><AccountTitle>LEITZ-AUSTRIA
>
> >
> >
> >>Vertriebs GmbH
> >>
> >
> >
> </AccountTitle></Account><Account><AccountNumberOLAV>57905627980</AccountNumberOLAV><AccountCurrency>EUR</AccountCurrency><AccountType>DD</AccountType><AccountProductNumber>00780</AccountProductNumber><AccountRole>ZBE</AccountRole><AccountBLZ>12000</AccountBLZ><AccountTitle>LEITZ-AUSTRIA
>
> >
> >
> >>Vertriebs GmbH </AccountTitle></Account></Userdata>"
> >>20060119 17:00:53,854 httpclient.wire.content DEBUG<< "[\r]"
> >>20060119 17:00:53,861 httpclient.wire.content DEBUG<< "[\n]"
> >>20060119 17:00:53,868 httpclient.wire.content DEBUG<< "0"
> >>20060119 17:00:53,874 httpclient.wire.content DEBUG<< "[\r]"
> >>20060119 17:00:53,881 httpclient.wire.content DEBUG<< "[\n]"
> >>20060119 17:00:53,888 httpclient.wire.content DEBUG<< "[\r]"
> >>20060119 17:00:53,894 httpclient.wire.content DEBUG<< "[\n]"
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org