Actually what is happening is this.... You are using a buffered stream. It is reading past the amount returned....and then the tcp/ip socket is blocking because you have it open as a keep alive. You have to only read the number of bytes available and not keep trying to squeeze the blood out of the turnip... ;-) I'll almost bet you money that is what is happening. Try to not use a buffered input stream and see what you get. If I'm wrong I'm wrong let me know. Hope it works.
Wade, thanks so very much for responding. I was sitting here dumbfounded wondering what in the world could be happening.
But you're wrong. ;)
I had already thrown out the BufferedInputStream to eliminate that. I switched to straight sockets. I set up a simple loop that simply read bytes until receiving a timeout. The timeout occurred after the CRLF divider, even though the Content-Length said 952. Accessing the site from Firefox showed all the content.
Puzzled? Yeah, so was I. Then I realized that in my Java client I was testing my new HTTP routines with the HEAD method!
(You can start the ridicule, now...)
The whole point of the HEAD method is that it doesn't send content---it simply sends a Content-Length indicating how long the content would have been. In fact, RFC 2616 says that "the server MUST NOT return a message-body in the response" for the HEAD method (9.4).
Now, what threw me off is that the response was an error status, a 401 Unauthorized. The Content-Length is in line with the spec, returning the length of the content which would have been returned if a GET had been used. As an error was returned, however, the Content-Length was returning the length of the error message---the error message that would have been returned had a GET been used.
Now, all this is technically to the letter of RFC 2616, but I wonder what would happen if a server were to send back a 405 Method Not Allowed for HEAD. There would be no way to get at the error message, because HEAD doesn't send back content. Using GET would succeed, so technically the Content-Length of HEAD in this case wouldn't be the content length of a response from GET.
I'm thinking that RFC 2616 should probably have made an exception to the no content rule for HEAD when an error condition is being reported. But that's the least of my worries. I just need to tell my client to ignore all content in a response to HEAD. Oddly, though, this means that a thread can't simply pull HTTP responses down from a persistent connection without knowing to which request each response belongs---i.e. whether to trust the Content-Length or not!
In any case, thanks for the input. It looks like your responses will be useful when I finally switch over to non-blocking I/O support.
Garret
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
