By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,553 Members | 1,128 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,553 IT Pros & Developers. It's quick & easy.

Using HttpURLConnection to POST to Servlet in Tomcat 5 results in GET not POST on server side

P: n/a
Does anyone know what is wrong with this code or why I might be experiencing
this behavior?

I have a Java application that submits HTTP POST requests to a servlet (with
content in the body of the request). I am using the java.net package. My
system worked fine with Tomcat 4.1.18: the servlet was invoked with a POST
request and it could read the content of the request using an InputStream.
But when I deploy my servlet in Tomcat 5 it no longer is invoked as a POST,
but rather a GET (the doGet method is called instead of the doPost, which is
called when deployed in Tomcat 4). The Serlvet therefore does not get the
body of the request (the Servlet's InputStream has no content).

My client code looks like this:

String request = "test";
java.net.URL netUrl = new java.net.URL(http://localhost:8080/myservlet);
connection = (HttpURLConnection) netUrl.openConnection();

connection.setRequestMethod( "POST" );

connection.setRequestProperty("Content-Length", "" +
Integer.toString(request.getBytes().length));

connection.setUseCaches(false);

connection.setDoInput(true);

connection.setDoOutput(true);
DataOutputStream out = new DataOutputStream( connection.getOutputStream() );
out.writeBytes( request );

out.flush();

out.close();
BufferedReader reader = new BufferedReader( new InputStreamReader(
connection.getInputStream() ) );
String response = reader.readLine();
while( null != response )

{

System.out.println( response );
response = reader.readLine();

}

Does anyone have any ideas?

Thank you,

Steve
Jul 17 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a

"Steve" <no@email.given> wrote in message
news:Ci*****************@newsread2.news.pas.earthl ink.net...
Does anyone know what is wrong with this code or why I might be experiencing this behavior?

I have a Java application that submits HTTP POST requests to a servlet (with content in the body of the request). I am using the java.net package. My
system worked fine with Tomcat 4.1.18: the servlet was invoked with a POST
request and it could read the content of the request using an InputStream.
But when I deploy my servlet in Tomcat 5 it no longer is invoked as a POST, but rather a GET (the doGet method is called instead of the doPost, which is called when deployed in Tomcat 4). The Serlvet therefore does not get the
body of the request (the Servlet's InputStream has no content).

My client code looks like this:

String request = "test";
java.net.URL netUrl = new java.net.URL(http://localhost:8080/myservlet);
connection = (HttpURLConnection) netUrl.openConnection();

connection.setRequestMethod( "POST" );

connection.setRequestProperty("Content-Length", "" +
Integer.toString(request.getBytes().length));

connection.setUseCaches(false);

connection.setDoInput(true);

connection.setDoOutput(true);
DataOutputStream out = new DataOutputStream( connection.getOutputStream() );

out.writeBytes( request );

out.flush();

out.close();
BufferedReader reader = new BufferedReader( new InputStreamReader(
connection.getInputStream() ) );
String response = reader.readLine();
while( null != response )

{

System.out.println( response );
response = reader.readLine();

}

Does anyone have any ideas?

Thank you,

Steve


Try appending a slash (/) to the URL you are using to refer to the servlet.
Tomcat might have decided to do a redirect with the slash appended. I have
seen this behaviour before with other servlet containers also suddenly
introduced with new release versions.

Silvio Bierman
Jul 17 '05 #2

P: n/a
I discovered that Tomcat 5 was indeed doing a redirect (after appending the
"/"). Appending the "/" to the URL was the cure.

Thank you,
Steve

"Silvio Bierman" <sb******@idfix.nl> wrote in message
news:40***********************@news.xs4all.nl...

"Steve" <no@email.given> wrote in message
news:Ci*****************@newsread2.news.pas.earthl ink.net...
Does anyone know what is wrong with this code or why I might be experiencing
this behavior?

I have a Java application that submits HTTP POST requests to a servlet

(with
content in the body of the request). I am using the java.net package. My
system worked fine with Tomcat 4.1.18: the servlet was invoked with a POST request and it could read the content of the request using an InputStream. But when I deploy my servlet in Tomcat 5 it no longer is invoked as a

POST,
but rather a GET (the doGet method is called instead of the doPost, which is
called when deployed in Tomcat 4). The Serlvet therefore does not get
the body of the request (the Servlet's InputStream has no content).

My client code looks like this:

String request = "test";
java.net.URL netUrl = new java.net.URL(http://localhost:8080/myservlet);
connection = (HttpURLConnection) netUrl.openConnection();

connection.setRequestMethod( "POST" );

connection.setRequestProperty("Content-Length", "" +
Integer.toString(request.getBytes().length));

connection.setUseCaches(false);

connection.setDoInput(true);

connection.setDoOutput(true);
DataOutputStream out = new DataOutputStream(

connection.getOutputStream() );


out.writeBytes( request );

out.flush();

out.close();
BufferedReader reader = new BufferedReader( new InputStreamReader(
connection.getInputStream() ) );
String response = reader.readLine();
while( null != response )

{

System.out.println( response );
response = reader.readLine();

}

Does anyone have any ideas?

Thank you,

Steve


Try appending a slash (/) to the URL you are using to refer to the

servlet. Tomcat might have decided to do a redirect with the slash appended. I have
seen this behaviour before with other servlet containers also suddenly
introduced with new release versions.

Silvio Bierman

Jul 17 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.