extra CR characters when I send a paste

[NemoDacremont]

Describe the bug

I'm mainly using linux, and the line separator is \n, but when I upload files to wastebin, they are converted to use CRLF.

It seems to happen when, or before, sending the file to the API, the data in the POST request contains the CR chars

It can be annoying when using shebang :

> ./fSTkBd.py
env: ‘python\r’: No such file or directory
env: use -[v]S to pass options in shebang lines

How to Reproduce?

1. Upload a python file that uses \n as line separator to wastebin (or just copy paste) :

#!/bin/env python
print("HelloWorld!")

which is in hex format :

00000000: 2321 2f62 696e 2f65 6e76 2070 7974 686f  #!/bin/env pytho
00000010: 6e0a 7072 696e 7428 2248 656c 6c6f 576f  n.print("HelloWo
00000020: 726c 6421 2229 0a                                           rld!").

2. Download it (no copy paste)
3. Read the hex data of the file, it should be like that :

00000000: 2321 2f62 696e 2f65 6e76 2070 7974 686f  #!/bin/env pytho
00000010: 6e0d 0a70 7269 6e74 2822 4865 6c6c 6f57  n..print("HelloW
00000020: 6f72 6c64 2122 290d 0a                                  orld!")..

We can see there is extra characters 0x0d before the 0x0a (\n)

[NemoDacremont]

After looking quickly, it seems like it's an expected behaviour to have CRLF : https://stackoverflow.com/questions/6963480/firefox-and-chrome-replacing-lf-with-crlf-during-post

I feel like wastebin shouldn't alter the content of a file on upload or download

[matze]

I feel like wastebin shouldn't alter the content of a file on upload or download

Which would mean using the JSON API to POST the data. Hmm … wanted to avoid that to be honest.

[NemoDacremont]

I'm currently going through the code, so I still don't know everything, but is it an issue ?

[matze]

It requires users to have Javascript enabled. So far, I tried to use JS only for sugar but not essential functionality.

[NemoDacremont]

Oh ok it makes sense, I didn't get that and I kind of like the idea, isn't there any work around ?

[matze]

I will check. Interestingly, the pastebin.com OG also uses form data and I don't think it's a common complaint.

Edit: apparently it uses a different form encoding.

[NemoDacremont]

If you want, I can try to add a PR and check if it works locally

[matze]

Try but please also add a test that breaks on the current behavior.

[NemoDacremont]

Yeah no problem, I'll try

[NemoDacremont]

after struggling with rust (i'm not used to it), i found that : https://stackoverflow.com/questions/19349924/line-endings-in-a-form-textarea

seems like it's not doable without js sadly, the HTML specs define the newline in textarea being CRLF.

after testing, pastebin has the same issue, when I download the paste, it has extra \r

[matze]

It should be possible to switch to the other encoding, I will give it a shot later tonight.

[NemoDacremont]

I've created a draft PR with what I wrote, it supports multipart forms, maybe it can save you some time, the rust code might not be the best

[NemoDacremont]

I've been thinking a little about it, and maybe we could use the api by default when javascript is enabled, and if it isn't, the onclick listener wouldn't be activated.

This means it would fallback on the x-www-form-urlencoded if js is not activated, and use the API if it is, what do you think about it ?

[NemoDacremont]

As I closed my draft PR, I think there is no satisfying solution