You didn't optimise as we suggested in the end, you're still building the 
content up in memory. As suggested by a few, write to a stream so nothing needs 
to consume your clients memory and will scale better

Sent from my iPhone

> On 3 Mar 2015, at 22:06, Alessandro Manzoni <[email protected]> 
> wrote:
> 
> Il 03.03.2015 09.47, Alexey Panchenko ha scritto:
>> I am curious about how the client code looks now, before we continue
>> complaining on the other end.
>> Just trying to be fair.
> 1           HttpClient httpclient = new DefaultHttpClient();
> 2           HttpPost httppost = new HttpPost(uri);
> 3           httppost.addHeader("Content-Type", "text/xml;charset=utf-8");
> 4           ByteArrayEntity entity = new 
> ByteArrayEntity(output.toByteArray());
> 5 //      StringEntity entity = new StringEntity(new 
> String(output.toByteArray()), ContentType.TEXT_XML);
> 6           httppost.setEntity(entity);
> 7           HttpResponse response = httpclient.execute(httppost);
> 
> That's it. Added line 3 and line 4 replaced line 5.
> 
>> 
>> On Tue, Mar 3, 2015 at 2:36 PM, Brett Ryan <[email protected]> wrote:
>> 
>>>> What confused me, is that I thought that tomcat should honor the
>>> encoding set inside xml, while it just use content-type encoding or its
>>> default one instead.
>>> 
>>> Thats the correct behaviour. Your servlet container may choose to inspect
>>> the POST data but there is no requirement for it to, thats up to you to
>>> implement a filter as mentioned earlier. What if your XML was malformed,
>>> what do you think it should do? The content could be anything for all it
>>> cares. What would your processor do if the header of the XML said the
>>> encoding was 8859-1, but the actual encoding was UCS-2? You wouldn't even
>>> be able to read the header reliably, you would have to perform a series of
>>> rereads to get the right encoding.
>>> ---------------------------------------------------------------------
>>> 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]

Reply via email to