How do I test the contents of a download in RestAssured? - rest-assured

I have a endpoint I want to test out. I'll call GET with it and it's supposed to download a zip file containing a csv file. I want to verify that the contents of that csv file is correct.
When I hit the endpoint in Postman, the headers look something like this:
content-disposition: "attachment; filename=filename.zip"
content-encoding: gzip
content-length: 4321
content-type: "application/zip"
vary: Accept-encoding
On the Rest-Assured response though, when I printed out response.contentType(), I got text/html; charset=utf-8. I was going to try to try to get the response byte in bytes[] and then see if it matches the content I'm expecting in the CSV file but since the content-type doesn't match what I'm expecting, I don't think I can do that.
Also, how do I check the content-disposition of my response?

Related

Check if Ruby request response is gzip encoded

On Net::HTTP.Get request to a URL with accept-encoding header set as gzip, how do I check if the response is gzipped, before calling Zlib unzipping on it?
Found the answer, doing a response['Content-Encoding'] returns gzip if the response is Gzip encoded and nil otherwise. Discovered the param value by inspecting the browser HTTP response headers.

What's wrong with this OData batch update query?

I followed the example from here but I cannot get this to work!
I can't see anything wrong with the update query and I can't think of what to change because it seems fine. I'm only testing with one request because I wanted to make sure it works first.
Here's the request's body:
--batch_hJUuHcmH7ADWhYbtkF0o9JWlq
Content-Type: multipart/mixed; boundary=changeset_oYIVi6ByvAtKBlI7hqFWoOwX7
--changeset(oYIVi6ByvAtKBlI7hqFWoOwX7)
Content-Type: application/http
Content-Transfer-Encoding: binary
MERGE PrescriptionService.svc/Prescriptions(1L) HTTP/1.1
Host: 192.168.10.179
Content-Type: application/json;odata=verbose
{"PrescriptionType":"RegularMedicationPrescriptionType","Page":"0","Comment":"whoaaaaaa"}
--changeset(oYIVi6ByvAtKBlI7hqFWoOwX7)--
--batch(hJUuHcmH7ADWhYbtkF0o9JWlq)--
I get a 202 Accepted so the "overall" batch request is not malformed. This is the response from the server:
--batchresponse_d8e813eb-0327-4518-9312-9b7a55d0da0c
Content-Type: multipart/mixed; boundary=changesetresponse_fc085e3b-68a8-46dd-86c6-334b1070607d
--changesetresponse_fc085e3b-68a8-46dd-86c6-334b1070607d--
--batchresponse_d8e813eb-0327-4518-9312-9b7a55d0da0c--
I tried POSTing to that same URL in the batch body to create an entity and it doesn't work either, so it has to be something with the request body.
What's wrong with the request's body?
The changeset boundary as specified in the header:
boundary=changeset_oYIVi6ByvAtKBlI7hqFWoOwX7
must match exactly the one used later on:
--changeset(oYIVi6ByvAtKBlI7hqFWoOwX7)
Which it doesn't. I don't know why you added the parenthesis, but they should not be there.
Same goes for the batch boundary itself.

Apache benchmark multipart/form-data

i'm facing a strange problem with apache benchmark post file.
I need to stress a feature that handles file upload. So, I googled about, and found a post describing how to build a post file properly. Its contents looks like:
--1234567
Content-Disposition: form-data; name="user_id"
3
--1234567
Content-Disposition: form-data; name="file"; filename="cf_login.png"
Content-Type: image/png
[base64 encoded file content]
--1234567--
The ab line is this:
$ ab -c 1 -n 5 -v 4 -T 'multipart/form-data; boundary=1234567' -p post_file.txt http://localhost:3000/files
When ab make the requests the generated header is the following:
INFO: POST header ==
---
POST /files.json/ HTTP/1.0
Content-length: 229
Content-type: multipart/form-data; boundary=simpleboundary
Host: localhost:3000
User-Agent: ApacheBench/2.3
Accept: */*
---
LOG: header received:
HTTP/1.1 500 Internal Server Error
Content-Type: text/html; charset=utf-8
Content-Length: 13265
X-Request-Id: 9ad57d19cd71886a1bb817d00fac651b
X-Runtime: 0.015504
Server: WEBrick/1.3.1 (Ruby/1.9.3/2012-04-20)
Date: Tue, 25 Sep 2012 13:54:29 GMT
Connection: close
The expected return is a raise params.inspect, that let me see if the data is arriving to the other side. If I remove the boundary I can see data received in params, but this is not what I want. I want to get a file upload.
Anyone has a tip? I will really appreciate it.
I found the answer, and decided to share with you.
After some struggle with the post file, I decided to create a php script just to output the $_FILES and $_REQUEST variables to see if the file was built correctly. Indeed, apache receive the file perfectly and I could see the file data, and other request params.
With Rails the same doesn't occur, and after reading the documentation of HTTP 1.1 multipart topic, I realize that the problem was related to the post file format.
When you built this kind of file, you need to build it in details, and this means include all the special characters like \r and \n in the right place. The multipart does now work with "\n" at all, it needs "dos" line ending "\r\n".
So the correct post file looks like this (the \r\n is for illustration, but should be there, you know?):
--boundary_hash\r\n
Content-Disposition: form-data; name="your_form_field";\r\n
Content-Type: text/plain\r\n
\r\n
your form field data\r\n
--boundary_hash\r\n
Content-Disposition: form-data; name="another_field";\r\n
Content-Type: text/plain\r\n
\r\n
another field data\r\n
--boundary_hash\r\n
Content-Disposition: form-data; name="filename"; filename="cf_login.png"\r\n
Content-Type: image/png\r\n
\r\n
base64 file content\r\n
--boundary_hash--\r\n
When you open this file you see this actually:
--boundary_hash
Content-Disposition: form-data; name="your_form_field";
Content-Type: text/plain
your form field data
--boundary_hash
Content-Disposition: form-data; name="another_field";
Content-Type: text/plain
another field data
--boundary_hash
Content-Disposition: form-data; name="filename"; filename="cf_login.png"
Content-Type: image/png
base64 file content
--boundary_hash--
I hope that helps you.
Cheers.

Submitting a file to Desire2Learn Dropbox

Trying to submit a file to the Dropbox through PHP to a Desire2Learn Learning Suite. I don't see a field name documented to contain the file. Am I missing something?
No, you are not missing something. There is no field name for the file for dropbox submissions. Leave the name attribute as an empty string when posting the submission file.
Here’s what a submission request should look like:
POST http://{domain_name}/d2l/api/le/{version}/{org_unit}/dropbox/folders/{folder_id}/submissions/mysubmissions/?x_a={app_id}&x_b={token_id}&x_d={token_sig}&x_c={app_sig}&x_t={time} HTTP/1.1
Content-Type: multipart/mixed; boundary=8cf23611201b7ae
Host: {domain_name}
Content-Length: 775926
--8cf23611201b7ae
Content-Type: application/json
{"Text":"Here you go","HTML":null}
--8cf23611201b7ae
Content-Disposition: form-data; name=""; filename="Jellyfish.jpg"
Content-Type: image/jpeg
{binary data}
--8cf23611201b7ae--

OData batch multipart format and Content-ID

I'm trying to implement an odata consumer, specifically right now related to doing batch operations and change sets, following the odata documentation essentially loads to this sample multipart batch that I've used as a basis.
However when I actually run this batch code (via fiddler request builder for example) updated with my own entity paths and such, I receive the following error:
Error processing batch request. At the
start of every operation, exactly two
headers need to be specified:
'Content-Type' and
'Content-Transfer-Encoding'. Make sure
these headers are present and have the
correct values.
If I remove the Content-ID from the change set the change set works correctly, but obviously the later operations no longer work because they reference this Content-ID.
I've attempted to move the Content-ID header out of the change request multipart.. part headers, and into the actual part payload request headers, ie:
--changeset(77162fcd-b8da-41ac-a9f8-9357efbbd621)
Content-Type: application/http
Content-Transfer-Encoding: binary
Content-ID: 1
POST /service.svc/Customers HTTP/1.1
Host: host
Content-Type: application/atom+xml;type=entry
Content-Length: ###
<AtomPub representation of a new Customer>
becomes
--changeset(77162fcd-b8da-41ac-a9f8-9357efbbd621)
Content-Type: application/http
Content-Transfer-Encoding: binary
POST /service.svc/Customers HTTP/1.1
Host: host
Content-Type: application/atom+xml;type=entry
Content-Length: ###
Content-ID: 1
Again this no longer complains about the change set having only headers, but still the later reference the content id fails with
HTTP 404, Resource not found for the segment '$1'
The request part which references this content-id looks something like this:
--changeset_7448d3fc-39f6-49bb-b822-30fa4a1676ce
Content-Type: application/http
Content-Transfer-Encoding: binary
POST http://example.org/test.svc/$1/$links/Resources HTTP/1.1
Content-Type: application/json
.. json ..
Assume that http://example.org/test.svc is the service root.
The documentation isn't very clear really about the format of the inner request locations, so the path reference may be incorrect.
Hopefully somebody has better understood this aspect and can advise, thanks in advance.
Stephen.
Turns out you cannot refer to a change set request if the operation in this way if the operation isn't a POST, this makes sense from the aspect that only POST methods really require this reference, but it would be useful to not need this branching logic.
Importantly however the path when referencing the Content-ID should not be absolute, but instead simply:
POST $1/$links/Resources HTTP/1.1
Content-Type: application/json

Resources