In JMeter, the HTTP samplers are limited to either: - URL parameters (GET) - name-value variables (POST) This limits the content body that is sent - for e.g.: an arbitrary MIME document can't be sent. It would be good if all the HTTP Request samplers had an option to load an arbitrary file from disk as their content body.
I've just looked at the code in 2.0.2, and as far as I can see, one can send any file with any MIME type. So I'm not sure what the problem is - also I don't know how to check if POST is working OK. Can you supply a test-case?
(In reply to comment #1) > I've just looked at the code in 2.0.2, and as far as I can see, one can send any > file with any MIME type. > So I'm not sure what the problem is - also I don't know how to check if POST is > working OK. > Can you supply a test-case? Yes, one can send any file with any mime type. Follows an excerpt of what is sent by browsers or JMeter HTTP sampler: HTTP Headers Content-type: multipart/form-data; boundary=--------------------------- 7d159c1302d0y0 HTTP Body ---------------------------7d159c1302d0y0 Content-Disposition: form-data name= "form file fieldname" filename= "file name" Content-type: "file mime type" File Contents........... ---------------------------7d159c1302d0y0 However we would like to be able to send any type of information in the body, i.e. HTTP Headers Content-type: Any (it doesn't matter because the HTTP sampler should send the body as is..). HTTP Body Any data ( binary, ASCII, EBCDIC ..). Not necessarily loaded from a file. Maybe what confuses you is that we suggested to load it from a file because that is much easier that transcript it with some Hexa editor into the JMeter GUI and also it could be a long file. Our testcase: POST http://xxx.xxxxxxxxxx.xx/xxxx/xxxxx/xxxxx/ HTTP/1.1 Host: xxx.xxxxxxxxxx.xx Authorization: XXXXXX XXXXXXXXXXXXXXXXX Connection: close Content-Type: application/octet-string Content-Length: 30 Body 30 characters EBCDIC We did the trick to intercept the request with the HTTP Proxy Server and we got the binary body data as the first parameter name (as expected). We could also send it back to the server (no encode) the same way and it worked. But we rather prefer to load it from a file and not misuse the method parameters. Hope it helps
Sorry, I still don't undestand what is wrong with the exising HTTP Sampler. You say that one can send any file with any Mime type. Is that not enough? What is missing or wrong with the existing file processing? Does the file content get changed in some way? Or are some headers wrong or missing?
Sebb - the problem with existing HTTP sampler is one cannot submit arbitrary data in the content body. For instance, I don't think one can submit a multi-part MIME document - where the first MIME part is an XML document, the second MIME part is a text document, a third is binary, and so on. The 2.0.1 HTTP sampler seems limited to sending a single file in an HTTP request, as a single name-value pair.
(In reply to comment #3) > Sorry, I still don't undestand what is wrong with the exising HTTP Sampler. > You say that one can send any file with any Mime type. Is that not enough? > What is missing or wrong with the existing file processing? > Does the file content get changed in some way? > Or are some headers wrong or missing? There is nothing wrong with the existing file processing and there is no headers wrong or missing. Maybe that's why I suggested it was an enhancement and not a bug. We just need to send any data in the body request, not necessarily name/value pairs or a file. And one way to achieve this is to have this arbitrary data as the "contents" of a file loaded into the request body; But, it could be, in some cases, (depending of the data) transcript through the GUI. We are not talking about sending a file, we are talking about sending the contents. And these contents do not need any extra processing. That's something similar as it is done in the WebService Sampler. The WEB Service Sampler GUI allows you to enter the SOAP/XML-RPC Data or to load it from a file. For our purposes, is just enough if JMeter HTTP Sampler allows us to load it from a file and send it as is in the request body. Hope it helps
OK, I think I see now - the current sampler sends the contents of the file as is, but wraps it in some extra stuff that causes problems when trying to include mixed data. How about the following suggestion: if a file is specified, but the Parameter Name AND MIME type fields are blank, then only send the file contents, and omit: Content-Disposition Content-Type CRLF before CRLF after and the -- boundary markers before and after. Is this what you are after?
Created attachment 14503 [details] Allows to load arbitrary file contents as the request body using the HTTP Request sampler GUI
Sebb, thanks. What you propose is enough for our purposes. I have attached PostWriter.java to show you what we already coded to achieve it. We did the trick for all files with .bin extension. I'd rather prefer your idea and we feel more comfortable if you include it in JMeter source.
Created attachment 14703 [details] This patch adds a checkbox to the HttpRequest panel. If checked, the file is sent as the body of the request. This patch adds a checkbox to the HttpRequest panel. If checked, the contents of the specified file are written to the output stream of the connection.
Will this patch be made available on the 2.0.3 codeline (or in a nightbuild) in the near future?
Finally got around to this again. Sorry for the delay. JMeter now sends the file as the entire body of the POST request if both the file "name" and MIME type parameters are blank. Otherwise, the behaviour is as before. I did not add the extra checkbox, as it is now unnecessary. The code is in SVN, and will be in the next nightly build - see http://people.apache.org/builds/jakarta-jmeter/nightly/ if you want to try the code.
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/1519