Il 25.02.2015 19.28, Stefan Magnus Landrø ha scritto:
Few questions:
Why not use a more appropriate entity type? ByteArrayEntity? StreamEntity?
Should I? Why an entity would be more or less appropriate?
By the way, in version 4.2.2 I have no StreamEntity class. Docs says
that ByteArrayEntity has no encoding, while StringEntity does. That's it.
How do you consume the response?
Does it matter? The failure already happened.
By the way, I try to unmarshal response.getEntity().getContent(), as the
application waits for a returned xml stream.
If the unmarshal fails, I just write the content to the log file. In the
log I found that Tomcat returned an html page, with the notification of
the failure. This case 400 bad request, and I'm wondering why Tomcat
dislikes my request. That's not bad at all to me.
Sendt fra min iPhone
Den 25. feb. 2015 kl. 17.26 skrev Alessandro Manzoni
<[email protected]>:
I made a simple client that sends a xml stream to a webapp running on tomcat 7
by POST method.
Both client and tomcat run on the same server (linux). HTTPClient version is
4.2.2.
The xml stream is formally correct. Somtimes, when the stream is more than 30KB
tomcat replies with an html page reporting 400 bad request. When the stream is
smaller goes fine.
This is my code:
HttpClient httpclient = new DefaultHttpClient();
HttpPost httppost = new HttpPost(uri);
StringEntity entity = new StringEntity(new
String(output.toByteArray()), ContentType.TEXT_XML);
httppost.setEntity(entity);
return httpclient.execute(httppost);
where:
- uri is the uri of the webapp, always the same.
- output is a ByteArrayOutputStream that contains the xml stream
Should I put some more headers? Or change somewhat to avoid the error?
Thanks, regards.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
