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 [mailto:[EMAIL PROTECTED] 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 (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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
