|Subject:||RE: HTTP Response contains headers last|
|From:||Morris, Chris (Chri...@epsilon.com)|
|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? ;)
-----Original Message----- From: Roland Weber [mailto:ossf...@dubioso.net] Sent: Thursday, September 27, 2007 10:56 AM To: HttpClient User Discussion Subject: Re: HTTP Response contains headers last
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.
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
--------------------------------------------------------------------- To unsubscribe, e-mail: http...@jakarta.apache.org For additional commands, e-mail: http...@jakarta.apache.org The information contained in this communication is confidential, and is intended only for the sole use of the recipient named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message or any copy of it from your computer system. Thank you.