Bug 56161

Created attachment 31334 [details]
JMeter workbench

If I set up jmeter to use an HTTP Test Script Recorder and then use JMeter as a proxy for a PUT request which does not use the Expect: 100-continue mechanism then the data of the image is corrupted. I sent an email to the users list which is in the archive but doesn't appear to have been sent to the list (neither I (who had subscribed prior to sending) nor my colleague, who has been subscribed for a long time, got the email), the content of which was as follows:

"Hi,

We're playing around with JMeter at the moment and wanted to sit JMeter
between our test code and our backend HTTP service. We wanted to use
JMeter to record all the tests that were performed but when we enable
JMeter as an HTTP Proxy for our tests when a PUT request is made to
upload an image the binary image data going into JMeter (which has an
HTTP header Content-Type: image/jpeg) is considerably changed inside
JMeter.

I stuck a Charles proxy between the tests and JMeter and then between
JMeter and the backend so I could see exactly what went in and what came
out. I get the following results:

The Request headers (I'll not include the binary, but a hexdump of the
binary shows it to be malformed on exit) from our tests going into
JMeter:

PUT http://127.0.0.1:58082/image/abc HTTP/1.1
Host: 127.0.0.1:58082
Content-Length: 6504
Content-Type: image/jpeg
Accept-Encoding: gzip, deflate, compress
Accept: */*
User-Agent: python-requests/2.2.1 CPython/2.7.6 Linux/3.12-1-amd64

The request headers which JMeter sends:

PUT /image/abc HTTP/1.1
Connection: keep-alive
Content-Type: image/jpeg
Accept: */*
User-Agent: python-requests/2.2.1 CPython/2.7.6 Linux/3.12-1-amd64
Accept-Encoding: gzip, deflate, compress
Content-Length: 11261
Host: 127.0.0.1:58082

You can see the Content-Length is totally different and so our tests
break when a following GET request doesn't get back the same data.

I'm using JMeter 2.11 (downloaded from the JMeter website) on Debian
Jessie.

In JMeter we've done the following:

1) Added an HTTP(S) Test Script Recorder to a blank WorkBench
2) Changed the Port number to 58081
3) Clicked start

Then we run our tests and get the results above.

Based on a bunch of searches we tried the following things which didn't
help:

1) Set the HTTP Sampler Settings->Type to Java
2) Added a BSF Post Processing element to the Recorder with the
following script: 'prev.setDataEncoding("UTF-8")'

I'm now totally stumped, any suggestions as to a fix would be greatly
appreciated, heck even just knowing what I'm doing is stupid would be
awesome so I can go down a different route!

If it looks like a bug I could boil down exactly what's happening to a
tiny script and submit it as a bug report.

Thanks,

Jonathan"

Since then I have further narrowed down that using the 100-continue mechanism means data will be correctly passed through the recorder.

I used the following curl command to test this:

http_proxy=127.0.0.1:8888 curl -v -H "Expect: " -H "Content-Type: image/jpeg" -T cat.jpeg 127.0.0.1:8082/image/abc

If I don't overwrite the expect header then the request works exactly as expected and the data is not corrupted (as was shown in the email referenced above).

Attached is the jmx file for the extremely simple Workbench I've got set up.

Thanks,

Jonathan