hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Balazs Szuecs <balazs.szu...@wave-solutions.com>
Subject Antwort: Re: Antwort: Re: HttpClient 3.0 rc4 hangs at the end of chunked response
Date Thu, 26 Jan 2006 21:57:54 GMT
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()

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?

I've found some newsgroup postings which suggest that this behaviour is a 
Tomcat bug, but I'm not sure about it.

What is your opinion?

thank you!

Balazs





Oleg Kalnichevski <olegk@apache.org> 
20.01.2006 17:10
Bitte antworten an
"HttpClient User Discussion" <httpclient-user@jakarta.apache.org>


An
HttpClient User Discussion <httpclient-user@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 <olegk@apache.org> 
> 20.01.2006 14:26
> Bitte antworten an
> "HttpClient User Discussion" <httpclient-user@jakarta.apache.org>
> 
> 
> An
> HttpClient User Discussion <httpclient-user@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]"
>>20060119 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


Mime
View raw message