I've now also tried using cURL to download the page, and that has exactly the same problem.
I use a command of the form: curl http://etc/etc -d "name=val&name=val" -o page.txt --no-keepalive --raw --trace trace.txt The server (or its application) seems to be broken. On 05/02/2008, sebb <[EMAIL PROTECTED]> wrote: > Just run a test with wire logging. The end of the log is as follows: > > << "[0x9][0x9]<div id="N1_filtres" class="sclear">[\n]" > << "[0x9][0x9] [0x9]" > << "[\r]" > << "[\n]" > << "0" > << "[\r]" > << "[\n]" > << "[\r]" > << "[\n]" > << "[\r][\n]" > > This clearly shows a chunk size of 0, which indicates the last chunk. > > If you have a look at a page request that works, you'll see that the > "0" chunk appears after the end of the html - as it should. > > As far as I can tell, JMeter and the other clients I used (wget, > Wireshark) are behaving correctly. > > On 05/02/2008, Benj <[EMAIL PROTECTED]> wrote: > > > > Ok. There's nothing helpful in httpclient.wire logs. > > There is - see above. > > > It seems that the problem occurs when response is >= 140ko. > > Before I could have larger responses because I needed to increase capacity > > of tree view listener up to 1Mo. > > Strange. > > It the same behaviour with or without using an apache httpd in front of the > > tomcat server. > > When I call a simple static html file of 300ko on the tomcat server, I've no > > issue. > > > > Probably because it does not need to use chunked encoding as it knows > the size in advance. Or at least the server may well process the file > differently. > Actually it does still use chunked encoding. > > Any idea ? > > -- > > Bj > > > > > > Oops, sorry about that. Now I see the problem. > > > > The data is being sent back as > > > > Transfer-Encoding: chunked > > > > which is often used for longer responses. > > > > It looks like there is a problem with interpreting the chunking. > > > > Now the fault applies to the Java and HttpClients (which use different > > HTTP implementations), and also to WireShark (0.99.6a) and wget. > > > > It seems very unlikely that all of these different implementations are > > wrong, so I suspect that there might be a problem with the server ... > > > > The HttpClient sampler can generate a wire log which should show the > > problem (it's rather verbose). > > > > Browsers tend to be much more lenient than some servers deserve... > > -- > > View this message in context: > > http://www.nabble.com/http-sampler-%3A-truncated-response-tp15269074p15294264.html > > Sent from the JMeter - User mailing list archive at Nabble.com. > > > > > > --------------------------------------------------------------------- > > 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]
