Bob Krause wrote:
>I have a client/server application suite built using J2SE. The two
>applications communicate using HTTP. The client connects to the server
>using the high-level URL and HttpURLConnection classes. The server listen
>for and services client requests using the low-level ServerSocketChannel
>and SocketChannel classes. The problem I'd like some advice on occurs when
>the server tries to read the content of a client's PUT (or POST) request.
>...etc...
Does the server look like it's getting a chunked Content-Transfer-Encoding
header from the client? If so, then you have to implement the chunked
protocol. I thought of this mainly because of this statement:
>* I can see from dumping the data to a console window that the content
>being received is the end part of what is being sent. Stated the other way,
>the part of the text that I'm sending that is not being received is the
>beginning. So if the text being sent consists of 100 lines, for example,
>I'm receiving something like the final 60 lines of that text on the
>receiving end.
I'm also wondering if the size of the POST or PUT content has an effect on
whether it works or not. Do smaller transfers work? Do they omit the same
size of initial material? If so, I'd guess that something isn't being
buffered or sent properly on the client. The Sun-standard
HttpURLConnection is extremely limited in what it can POST or PUT, and I
don't recall how well-behaved it is if you exceed its limited capabilities.
You could use the 'tcpdump' command to see if the client really is sending
what it should be. See 'man tcpdump' in Terminal.
Another possibility is that something is screwy with the Channel support on
server-sockets, or something in that vein. Or that you're simply not using
the ServerSocketChannel and/or its I/O streams correctly, though I can't
tell without all the code.
I realize your server-side code works when run on XP, but you don't say how
many CPUs you have, or what machine, or what OS versions, all of which may
be relevant. In short, it might work on XP by accident, or by a
side-effect of the platform's implementation. Or it might fail on Mac OS X
for side-effect ereasons.
Since it's easy to use the non-Channel ServerSocket class to listen and
accept() new connections, I suggest writing a simple server using that
older API and see if it works or not against your existing client. There
are many examples you can crib ServerSocket code from, which a little
googling should turn up. I've used that API many times and it works
consistently on Mac OS X, either same machine or different ones, with or
without CR-LF's, interop with XP or not, and with or without HTTP.
The trick to writing an HTTP server is you have to be fastidious in how you
implement the HTTP protocol. It's easy to get it wrong, and even tiny
mistakes or omissions can have big consequences. Also, it's a lot easier
to implement HTTP 1.0 than 1.1, and when I've done HTTP servers in the
past, that's always where I start.
As a cross-check, have your client send a POST to Personal Web Sharing on
Mac OS X, which runs the Apache server. Then hook it up to a simple CGI
diagnostic that tells you what it received. It's pretty easy to serve
pages with Personal Web Sharing, and it's reasonably straightforward to
configure it to run CGI's.
>* The problem occurs when 1) the client is running under MacOSX and the
>server is running under Windows XP, 2) client = XP & server = Mac, or 3)
>client = Mac & server = Mac. The problem does not occur if both client and
>server are XP based -- whether on the same XP box or different ones.
Are you perhaps using println() to a socket? Or perhaps using readline()
from a socket? If so, then the problem may be that you're not sending
CR-LF line-terminators.
<http://developer.apple.com/technotes/tn/tn1157.html>
All the above is little more than guessing and conjecture. Posting small
fragments of code tells nothing about the surrounding context, and in
client-server communication, context is crucial.
If none of the suggestions works out, I suggest creating a well-isolated
test-case that consistently exhibits the failure, and making it available
as a URL. Then post the URL to the list. One possible side-effect is that
the process of creating a well-isolated fail-case leads to a recognition of
a subtle latent bug in one's original code. I've done that a few times, so
ruthless simplication can have a reward.
-- 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
