another java hacking story, part 2

So do it myself means I open the socket, I write the output to the server, then I read the input from the server.

Means I have to write the "readLine" method. Again.

Well, anyway. Nothing I haven't done before. Except the business about "getErrorStream()" in HttpUrlConnection. What is that?

Took me a while to hunt down the right thing, which is the deeply buried Sun code for this class. What happens: normal process is for the header block to be read for you, then you call getInputStream() for the remainder. But if the return code is >=400, the header is read, and then:

InputStream instream = socket.getInputStream();
InputStream errstream = null;

// read header now.

// return code >= 400?

errstream = instream;
instream = null;


There you have it. There's only the one stream, from the socket. IN and ERR are flipped. You can't ever have both at the same time (note that this is different from an exec'd subprocess, but that's OS-level behavior for a process).

So the "content" that gets read from the socket is either the normal result, or it's the error message. Some messages are generated by the server (Tomcat), and some are from the servlet code.

OK, so no big deal to read all this. And yea, verily, with a couple initial errors readily fixed, it works as it is supposed to.

And I have a new tool.

And neither you nor I can trust HttpUrlConnection again. But with a new tool, who needs to?

Part 3 is the source for the final item. It isn't finished, I'm not handling the various other return codes, just those necessary for what I was doing at work. I'll fix up those things as I need to.