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 (
Date:Sep 27, 2007 10:03:31 am

Good point! I'll ask the folks who own the API that I'm accessing to move the record count and other API-specific status information to the HTTP response footers. That seems like a reasonable request. What do you think my chances are? ;)

Chris Morris

-----Original Message----- From: Roland Weber [] Sent: Thursday, September 27, 2007 10:56 AM To: HttpClient User Discussion Subject: Re: HTTP Response contains headers last

Hi Morris,

I'm working on a workaround using the HttpURLConnection ( 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.

You don't. At least not with the public API. HttpURLConnection will also automatically read in the head section. That's necessary to determine whether there is a body in the first place, and to evaluate the transfer encoding. If the transfer encoding is "chunked", HttpURLConnection installs a layered stream that takes care of decoding the chunks, just as HttpClient does.

If you're interested, the server actually sends the headers last on purpose. Reason being, it includes a header field containing a record count.

A guy called Peter Jackson once shot a movie called "Braindead". Readers of this mail are welcome to decide for themselves whether this remark is off-topic. The movie is funny, by the way. If you like splatter.

RFC 2616, that is HTTP 1.1, explicitly allows for footers (or rather trailers) in section 3.6.1 and elsewhere. These have to be properly announced in the headers, and can only be used in combination with chunked encoding. They might get lost by proxies. But no proxy would relay what your server is sending anyway.

If folks have to invent their own data format, they should just do so. Instead of pretending to "tweak" a standard. How is any receiver supposed to reliably detect the end of the entity with this <censored>? They have to scan the input, and then they might as well count the records themselves while scanning. *shiver*

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!

Sincere condolences, Roland