Hi Stefan,
thank you for the reply,
Il 25.02.2015 20.44, Stefan Magnus Landrø ha scritto:
2015-02-25 20:07 GMT+01:00 Alessandro Manzoni <[email protected]
:
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.
https://github.com/apache/httpcore/blob/4.2.2/httpcore/src/main/java/org/apache/http/entity/InputStreamEntity.java
Docs says that ByteArrayEntity has no encoding, while StringEntity does.
That's it.
You're reading the whole thing into memory. You'll get better performance
streaming. The encoding header can be set directly on the request. See
sources for details on which headers are set in case of string entity.
I saw that if a null encoding is used, StringEntity uses a default one,
that works just as expected with small (< 30kb) xml, so I have no
reasons not to trust it.
Since I produce the xml in memory, that's the way Marshal.marshal method
works, I could use the ByteArrayEntity using the byte[] from the
ByteArrayOutputStream supplied to marshal. But docs tell me that
ByteArrayEntity is not thread-safe, while I need to use HttpClient by
conncurrent threads.
Further more, I supect that the target Tomcat dislikes my request due to
incongruents content and content-lenght or a buffer too small somewhere.
I don't see anything to do with the entity that matches this figure.
Tomcat logs do not show anything about the reason not to accept the
request.
I need some hint to investigate further, maybe just to say it's not
HTTPClient fault.
Fair enough. You should see details in the tomcat logs concerning the 400
error code. Are you controlling the application you're hitting?
Not directly, just logs.
I was told that target application logs received requests as soon as is
invoked and always replies with an xml carrying an error indicating
failing items. When the problem arise, I don't find any log about, and
the only response received is tomcat error page.
Then when Tomcat reject the request, usully is because of an uncathed
exception (that cause a 500 reason code, and the exception appears in
tomcat logs) or some filter prevent to invoke the target application
(but I should see this in tomcat logs and reason code would be some 40x
reason code but 400), or it evaluate the request as malformed (that
resuts in a 400 reson code). Isn't it?
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.
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]
