Wednesday, February 27, 2008

Uploading files Using OpenSTA

Uploading files Using OpenSTA

This page has been created as a home for more information about the problems when recording and replaying Multipart HTTP forms.

Multipart forms are used for file uploading in HTTP, so if you don't understand HTTP that well you may be looking for information specifically on this - it's here!

The OpenSTA 1.4.3 release contains fixes for most of these problems - please upgrade and add more text here if you still have issues.

OpenSTA 1.4.3 does not have a complete fix, it needs patching -

If you are using HTTPS then you are limited to a total request size of 16K by this bug, although this isn't specifically a multipart/form-data issue, many times it is these type of requests which are over 16K.

Most recording and playback of multipart/form-data issues appear to occured in OpenSTA installations prior to 1.4.3 and take several forms:

Uploading a binary file may cause the Gateway to hang during recording Here is the bug report:.
If binary data is being uploaded and there is more than 255 bytes of data in the POST, the script will not capture the POST BODY and will represent it in the script as: BODY "binary(N) this is an undocumented feature and during replay the binary(NNN) will be replaced by N 'A' characters. This is probably not what you want. Here's the bug report:
With less data than the above limit, the body will be coded as "0xXXYYZZ..." where the pairs of characters represent the hex value of a byte.
If you managed to record the BODY of the POST, you may see " ^J" dispersed throughout the BODY or the generated SCL badly broken over several lines. This is this bug report:
Playing back scripts with POST bodies containing NULLs may not work correctly. Seems to work as long as the NULLs are encoded (~<00> or ^@). There may still be something in it though and here's the related bug report:


The following details were originally supplied by Antony Marcano, with compliments of etest associates

OpenSTA interprets this "^J" at playback as ASCII code 0x0A (linefeed). A multipart form requires that each attribute is separated by 0x0D (carriage return) and a 0x0A (linefeed).

^J = 0xOA = ~<0A> = ~ = linefeed character
Replace all "^J" with "~<0D>~<0A>", (or "~~") making sure that you get any that are split due to the restriction on the maximum length of a line in SCL. e.g. your POST should look something like this:

POST URI "http://test.osta.lan/upload.php HTTP/1.0" ON 1 &
"Accept: image/gif image/jpeg */*", &
"Content: multipart/form-data; boundary=-----------------------------d721fa3080192", &
"Content-Length: 0"
"-----------------------------d721fa3080192~~" &
"Content-Disposition: form-data; name=~<22>upfile~<22>; filename=~<22>myfile.rtf~<22>~~" &
"Content-Type: application/msword~~" &
"~~"+FILECONTENT+"~~" &

The Content-Length (here 0 as an illustration) in the CLIENT HEADER is automatically recalculated at playback and does not need to be edited.
If the file upload has more than just the file upload in it you will see many more boundary strings and the rest of you form data encode there.
The last boundary string has additional "--" designating it as the end.
Your FILECONTENT must be a character*N (at this time), constants seem to break the concatenation in a POST BODY.
Your FILECONTENT is limited by the max size of character variable so you might have to break it up and do FILECONT1 + FILECONT2 + FILECONT3 .
Your FILECONTENT needs to be SCL encoded, ie all non-printing characters translated into ~<''XX''> format
WORK-AROUND for Binary Body
HINT - Use a sniffer to capture unrecordable POSTs, then save in a text file that you edit into an OpenSTA script.
HINT - Upload a very small text file to get your template SCL and then translate your binary file into variable(s) as above and insert into the SCL.
WORK-AROUND for Gateway Hang
HINT - Record the script in two parts: before and after the post then use the Work Around for Binary Body (above) to create the code for the PRIMARY POST

No comments: