thunder-client-support icon indicating copy to clipboard operation
thunder-client-support copied to clipboard

Incorrect File Path in Windows

Open ibirman-vbrick opened this issue 3 years ago • 5 comments

Describe the bug

When adding a file using the Files option under Form Fields on a Windows computer, the Path to the file is created as an absolute path from C:, but the backslashes aren't escaped so it doesn't work.

formdata.append("", fs.createReadStream("C:\temp\shipit.jpg"));

But it should have double backslashes instead.

To Reproduce

  • Create a new Request
  • Click on Body
  • Click on Form
  • Click on the checkbox next to Files
  • Click Choose File and select a file
  • Click on Code Snippet and select Javascript Axios
  • Observe that the file has an absolute path with single backslashes: "C:\temp\file.jpg"

As a result, file uploading fails to work, the back end receives an empty request.

Expected behavior

The path should have properly escaped backslashes: "C:\\temp\\file.jpg"

Platform:

  • OS: Windows 10
  • vscode version: 1.67.2
  • extension version: 1.16.5

Solution:

ibirman-vbrick avatar Jun 23 '22 20:06 ibirman-vbrick

@ibirman-vbrick thanks for the feedback, will add to roadmap.

rangav avatar Jun 23 '22 20:06 rangav

here is the code snippet project link, if you like you can fix it and submit PR. https://github.com/rangav/thunder-codegen

rangav avatar Jun 23 '22 21:06 rangav

Just to be clear, this issue is not just with code snippets, all file uploads fail in Windows.

ibirman-vbrick avatar Jun 24 '22 03:06 ibirman-vbrick

How did you verify the paths are not working in windows?

you can test upload of sample file to below url https://httpbin.org/anything

rangav avatar Jun 24 '22 04:06 rangav

@rangav you are correct, the path issue with snippets is different from the upload issue I'm having. I am trying to upload using multipart/form-data and it doesn't seem to send any data. I need to do more testing with that, it's probably a separate issue from what I posted above.

ibirman-vbrick avatar Jun 24 '22 13:06 ibirman-vbrick

I have encountered the same issue with multipart forms on Windows.

I am moving my requests from rest-client to thunder-client, and the former uploads a file using multipart/form-data and it works as expected.

The same thing in thunder-client however, does not work.

Just to be clear, this issue is not just with code snippets, all file uploads fail in Windows.

I think the internally used client also does not escape paths correctly on Windows, hence why the file is not actually uploaded since it cannot be found in the first place.

My API responds with Multipart form parse error - Invalid boundary in multipart: None, possibly indicating that there is no actual binary data inserted in the body in the part where the file should go.

In rest-client I had to use < ./logo.png in the file part of the multipart form to actually put the binary data in the request. The generated HTTP snippet in thunder-client doesn't have anything for the file:

POST /attachments/ HTTP/1.1
Accept: */*
User-Agent: Thunder Client (https://www.thunderclient.com)
Content-Type: multipart/form-data; boundary=---011000010111000001101001
Host: 127.0.0.1:8000
Content-Length: 250

-----011000010111000001101001
Content-Disposition: form-data; name="name"

File Feeney
-----011000010111000001101001
Content-Disposition: form-data; name="file"; filename="logo.png"
Content-Type: image/png


-----011000010111000001101001--

you can test upload of sample file to below url https://httpbin.org/anything

If I upload to there with thunder-client it doesn't show any file uploaded.

With curl (from WSL):

curl -X POST 'https://httpbin.org/anything' --header 'Accept: */*' --header 'User-Agent: Thunder Client (https://www.thunderclient.com)' --header 'Content-Type: multipart/form-data' --form 'name="File Casper"' --form 'file=@./logo.png'`
{
  "args": {},
  "data": "",
  "files": {
    "file": "data:image/png;base64,iVBORw ... Jggg=="
  },
  "form": {
    "name": "File Casper"
  },
  "headers": {
    "Accept": "*/*",
    "Content-Length": "4616",
    "Content-Type": "multipart/form-data; boundary=------------------------f5e5208243e054b1",
    "Host": "httpbin.org",
    "User-Agent": "Thunder Client (https://www.thunderclient.com)",
  },
  "json": null,
  "method": "POST",
  "url": "https://httpbin.org/anything"
}

With thunder-client

{
    "args": {},
    "data": "",
    "files": {},
    "form": {},
    "headers": {
        "Accept": "*/*",
        "Accept-Encoding": "gzip, deflate, br",
        "Content-Length": "4645",
        "Content-Type": "multipart/form-data",
        "Host": "httpbin.org",
        "User-Agent": "Thunder Client (https://www.thunderclient.com)",
    },
    "json": null,
    "method": "POST",
    "url": "https://httpbin.org/anything"
}

(the content length is set correctly, but there is no actual file data, unlike with the curl request)

ThenTech avatar Dec 06 '22 22:12 ThenTech

@ThenTech thanks for reporting the issue.

how did you upload the file in thunder client?

Can you share screenshot of form tab?

rangav avatar Dec 07 '22 04:12 rangav

When trying to set it up again (to https://httpbin.org/anything) in the Activity tab, it actually did work correctly.

Looking at the differences, in my collection settings I put a default Content-Type: application/json, so in my upload request I overwrote it to Content-Type: multipart/form-data since that is what I want to use. But it looks like Thunder prefers the user set Content-Type and does not override it, even though it needed to be different depending on what is chosen in the body.

If I remove the default header from Collection settings and also remove it from the request Headers section, Thunder does actually put in the correct header (which should include the multipart form boundary, like Content-Type: multipart/form-data; boundary=---XXXX).

So the solution then, in my case at least, is to not set the Content-Type header myself.

@ibirman-vbrick Did you also set the Content-Type header manually?

ThenTech avatar Dec 07 '22 12:12 ThenTech

@ThenTech good it's working for you now.

Content-type header is automatically calculated and send with the request by extension.

rangav avatar Dec 07 '22 12:12 rangav

Yes, though like I said, if I enter a Content-type manually in the request Headers tab, it will be used instead of any calculated data.

ThenTech avatar Dec 07 '22 12:12 ThenTech

Closing this issue, feel free to re-open if needed

rangav avatar Mar 09 '23 04:03 rangav