https://issues.apache.org/bugzilla/show_bug.cgi?id=56161
Bug ID: 56161
Summary: Data is corrupted on PUT request when not using
100-continue
Product: JMeter
Version: 2.11
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: HTTP
Assignee: [email protected]
Reporter: [email protected]
Created attachment 31334
--> https://issues.apache.org/bugzilla/attachment.cgi?id=31334&action=edit
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
--
You are receiving this mail because:
You are the assignee for the bug.
