> Hi everybody,
>
[quoted text clipped - 14 lines]
>
> how to avoid that?
I don't think the bug is in those four lines. What you need is a good
debugger and I recommend jSwat: http://jswat.sourceforge.net/
By the way, you can also pass GET-like parameters to a POST request:
POST somefile.php?hello=world HTTP/1.1
....
Vittorix - 30 Jan 2008 03:38 GMT
>> I'm writing a web server in Java for html and servlets.
>> when the server receives a GET request, it works fine.
[quoted text clipped - 15 lines]
> I don't think the bug is in those four lines. What you need is a good
> debugger and I recommend jSwat: http://jswat.sourceforge.net/
yes, it was, and I solved the problem using read() instead of readLine() in
this way:
else if(method.equals("POST"))
{ // POST method
int ch;
int len = Integer.parseInt((String)
headers.get("Content-Length")); // POST request Content-Length header
paraLine = "";
for(int i=1; i<=len; i++)
{
ch = in.read();
paraLine += (char) ch; // in the POST request,
the parameters are in the http request body
}
}
> By the way, you can also pass GET-like parameters to a POST request:
> POST somefile.php?hello=world HTTP/1.1
this is fun

Signature
ciao
Vittorix
Robert Larsen - 30 Jan 2008 06:19 GMT
>> By the way, you can also pass GET-like parameters to a POST request:
>> POST somefile.php?hello=world HTTP/1.1
>
> this is fun
hehe, yup
I have played a lot with HTTP myself. It is just an extremely convenient
way of displaying a lot of information and reconfigure running software.
I have eight different types of servers running in production, each with
its own web interface. Very nice.
>I'm writing a web server in Java for html and servlets.
In general, I'd recommend reusing one of the MANY choices already available.
Tomcat or Jetty are the ones I'd start with, but
http://java-source.net/open-source/web-servers lists plenty to choose from.
Writing one for your own education is fine, of course, but I'd recommend start
small, maybe static files and a subset of the servlet spec.
>when the server receives a GET request, it works fine.
>problem: when I use POST, the server program stops and the submit button has
>to be clicked another time or the page has to be manually refreshed (after
>that it works fine).
Umm, you're mixing up client and server behavior. If you're going to write an
http server, do NOT use a browser as your primary test harness. Use a test
client that gives you control over content, and validates the return rather
than rendering it.
I'd probably use the Jakarta Commons HttpClient package, run from JUnit.
>so, the program waits for the client to send a new signal/request.
>The problem is caused by a in.readLine() statement:
[quoted text clipped - 3 lines]
> paraLine = in.readLine(); // in the POST request, the parameters are
>in the http request body
1) Fire up a command-line post utility and see what's really going on. Or
install LiveHTTPHeaders in firefox. It's very likely that you're assuming a
format that doesn't actually match what's transmitted. And it's equally
likely that the bug isn't in this snippet of code, but somewhere around it.
2) Using blocking buffered IO in a server like this is asking for trouble.
Even if you get it working correctly, you're setting yourself up for pain when
you encounter a browser that behaves incorrectly. You should read blocks of
data, and parse them as needed.
--
Mark Rafn dagon@dagon.net <http://www.dagon.net/>