Bob Krause wrote:
> Connection: keep-alive
Set the outgoing request's header to be a closed connection, not
keep-alive. The fact that the second request fails makes me think that
keep-alive might be mishandled somewhere.
>Sorry, I meant to mention in my initial posting that this error occurs with
>content sizes as short as 128 bytes. (Maybe smaller, but 128 was the
>smallest test I've run so far.) I've also tried my "real world" 15K as well
>as 1K, 2K and 5K and I always receive only part of the data.
Do you always receive only the LAST part of the data?
I suggest even smaller content sizes, like 8, 16, or 32 bytes. If it
continues to receive only part of what's sent, is it always the last part?
Exactly how big is the last part? Is it always exactly half of what it
should be, which is a clue that some measurement of content-size or an
encoding is broken.
>This problem shows up in just the second HTTP request my application makes.
Meaning what? That the 1st and 3rd ones work fine? That in a sequence of
1000, only the 2nd one is broken, or every other one is broken, or all but
the 1st one is broken?
I assume "my application" refers to the client.
>I'm running MacOSX 10.4.4 on a dual G5 2GHz with 2GB of memory.
Your Mac has dual CPUs and your XP doesn't. So try running the Mac with
only 1 CPU.
<http://developer.apple.com/qa/qa2001/qa1141.html>
I don't think it will change anything, but since I'm just guessing, it's
worth a shot.
>I guess another point worth making is that the request that I'm having a
>problem with works fine in all other respects if I don't open an
>OutputStream on the client or InputStream on the server.
That doesn't make sense.
A POST or PUT should have some body content, otherwise the Content-Length
is 0, which is certainly legal but rather pointless. The only way to
assign body content to a POST or PUT HttpURLConnection is by getting an
OutputStream on the client and writing to it.
And if the server doesn't open an InputStream, then you can't read either
the headers OR the content. So I guess in a vacuous sense that "works",
but it seems meaningless to me.
Or am I misunderstanding what you mean by "works fine in all other respects
if I don't open an OutputStream on the client or InputStream on the
server."?
This is one reason it's useful to see a complete program, rather than
snippets of code with external description. I can look at code to see what
it's doing, rather than trying to infer what its doing from a description.
>I know one thing that has worried me from the start is that the client code
>is using high-level HTTP connections while the server code is using
>low-level sockets. I was worried that getting these two sides to talk to
>each other might not be easy.
The high-level client code (HttpUrlConnection et al.) is written using
low-level sockets, so it makes no sense to worry about that.
What you should recognize is that HttpUrlConnection implements the HTTP
client-side protocol, but ServerSocket (with or without Channels) is a
plain unadorned TCP/IP socket that does NOT implement the HTTP protocol.
So by using ServerSocket, you are taking on the responsibility of writing
an HTTP server, however small or large, which must correctly implement the
HTTP protocol in order to talk to the HTTP client-side code in
HttpUrlConnection.
I strongly suggest using an existing known-working HTTP server, and seeing
if it works with your client program. If it does, then you know the
problem lies with your server-side code. That cuts the number of places
you have to look in half.
This HTTP server is very small, and only supports GET by default, but it's
easy to add support for PUT or POST, and you can make the handlers be
simple diagnostics, like an "echo" HTTP service:
<http://www.jibble.org/miniwebserver/>
It's GPL'ed and includes source (only 2 classes). It should be simpler to
modify it than writing your own HTTP server just for testing.
There's also the moribund Pygmy-httpd server project:
<ttp://sourceforge.net/projects/pygmy-httpd/>
Or see the SimpleWeb embeddable HTTP server:
<http://simpleweb.sourceforge.net/index.php>
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
