I'm using REST requests for functional testing. One of my use case is sending attachement in POST requests. In the content type of sent data (watched in httplog console), there is "Content-Type: application/pdf; name=<NameOfTheDownloadedFile>"
Why content-type contain downloaded file name (i.e. name=<NameOfTheDownloadedFile>) ? REST style request are not designed to contain this kind of value.
Hi,
Do you mean what is the purpose of the of that name=<file name> part of the Content-Type header?
If so, I think this is used to allow browsers without a PDF plugin installed to prompt the user to download the PDF as a file (named as per the name property).
Does the service you are calling set anything like:
...
response.setContentType("application/pdf");
// Tell browser to try to display inline, but if not,
// to save under the given filename.
response.setHeader("Content-disposition", "inline; filename=\"DispatchNote.pdf\"");
...
?
Cheers,
Rupert
Hi
Thanks for your rapid answer.
Do you mean what is the purpose of the of that name=<file name> part of the Content-Type header?
>>There is no purpose. The file name is added by soapUI not by my service.
Does the service you are calling set anything like:
...
response.setContentType("application/pdf");
>>Yes, the service do something like that. Since it is a service for document uploads, only few content types are authorized.
So I wonder why during the step of attachement, the file name is added in the contentType ? May be I'm wrong, but I think it's a bug in this step (see attached file).
Hi,
Sorry, I had thought from you're original post that it was your service under test that was setting that contentType, in which case adding the filename might be correct. Whereas it is infact SoapUI that is inserting the file name as part of the contentType property.
In the context of making a client call i.e. like SoapUI is doing in the Request TestStep, I must admit that I am not certain what purpose the filename would have when set as part of the contentType property, so could be a added unecessarily... I take it the actual PDF attachment is included as part of some kind of Base64 encoded multi-part message in the request?
Assuming the filename part of the contentType is a bug, does it cause your service an issue?
Thanks,
Rupert
