atom feed8 messages in org.apache.hc.httpclient-usersRE: HTTP Response contains headers last
FromSent OnAttachments
Morris, ChrisSep 26, 2007 11:53 am 
Roland WeberSep 27, 2007 8:32 am 
Morris, ChrisSep 27, 2007 8:48 am 
Roland WeberSep 27, 2007 9:16 am 
Morris, ChrisSep 27, 2007 9:24 am 
Roland WeberSep 27, 2007 9:55 am 
Morris, ChrisSep 27, 2007 10:03 am 
Roland WeberSep 27, 2007 10:57 pm 
Subject:RE: HTTP Response contains headers last
From:Morris, Chris (Chri@epsilon.com)
Date:Sep 27, 2007 9:24:05 am
List:org.apache.hc.httpclient-users

Thanks Roland! That aligns with my conclusion as well.

I'm working on a workaround using the HttpURLConnection (java.util.net) class. It's probably no where near as elegant or bullet proof as HttpClient, but at least I have direct access to the input stream so that I can parse it myself.

If you're interested, the server actually sends the headers last on purpose. Reason being, it includes a header field containing a record count. I don't think it's worth all the trouble that this has caused me. I'd much rather make a second API call to get the record count then have to deal with this, but, that's the way it is for now!

Thanks again for your help!

Chris Morris

-----Original Message----- From: Roland Weber [mailto:ossf@dubioso.net] Sent: Thursday, September 27, 2007 10:16 AM To: HttpClient User Discussion Subject: Re: HTTP Response contains headers last

Hello Chris,

that server is not only sending the headers last. It is sending the whole head section of the HTTP response after the body. That is not HTTP at all. Not even close. Even though the supposed body is listed in the output as "headers", that's not what HttpClient makes of it. HttpClient simply skips garbage lines at the beginning of a response, until it finds the line starting with "HTTP/1.1". Then, it reads in the head section. And then, it would try to read the body, except that there is none. There is not even the required empty line that terminates the head section.

I have two explanations for this. One: the server is using persistent connections, but gets confused by something the client does. That could happen if you use the SimpleHttpConnectionManager from multiple threads. But if that log is the full log of a test run, that's not what happens. Two: the server is totally screwed and has no idea of what HTTP specifies. In that case, you're best off by connecting directly to the server using a Socket. I'm sorry, but that behavior is way too far off to tweak HttpClient into tolerance.

cheers, Roland