hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessandro Manzoni <manzoni.alessand...@gmail.com>
Subject Re: 400 bad request POSTing to Tomcat 7.0.42
Date Thu, 26 Feb 2015 12:06:30 GMT
Il 26.02.2015 11.59, Stefan Magnus Landrø ha scritto:
> or a tcp dump if you prefer. Could it be a transfer encoding issue? Is
> there a proxy involved in this process?
The error is returned only with certain post (I noticed that only posts 
 >30KB are rejected), while the encoding is always the same as  posts 
that are succesfully accepted.
There is no proxy, the target Tomcat is on the same machine.
How can I dump tcp? It's a production server, do you mean to trace 
ethernet headers? As I told you both client and target tomcat are on the 
same machine, I don't know any utility able to trace localhost traffic. 
Can you advise one?

> 2015-02-26 9:50 GMT+01:00 Oleg Kalnichevski <olegk@apache.org>:
>> On Thu, 2015-02-26 at 08:26 +0100, Alessandro Manzoni wrote:
>>> Hi Stefan,
>>> thank you for the reply,
>> Post a wire log of the session exhibiting the problem.
>> Oleg
>>> Il 25.02.2015 20.44, Stefan Magnus Landrø ha scritto:
>>>> 2015-02-25 20:07 GMT+01:00 Alessandro Manzoni <
>> manzoni.alessandro4@gmail.com
>>>>> :
>>>>> 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 <
>>>>>>> manzoni.alessandro4@gmail.com>:
>>>>>>> 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
>> 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: httpclient-users-unsubscribe@hc.apache.org
>>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>> For additional commands, e-mail: httpclient-users-help@hc.apache.org

To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

View raw message