[GH-ISSUE #148] extra CR characters when I send a paste #90

Closed
opened 2026-02-27 10:15:40 +03:00 by kerem · 14 comments
Owner

Originally created by @NemoDacremont on GitHub (Apr 2, 2025).
Original GitHub issue: https://github.com/matze/wastebin/issues/148

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!").
  1. Download it (no copy paste)
  2. 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)

Originally created by @NemoDacremont on GitHub (Apr 2, 2025). Original GitHub issue: https://github.com/matze/wastebin/issues/148 ## 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 : ```sh > ./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) : ```py #!/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`)
kerem closed this issue 2026-02-27 10:15:40 +03:00
Author
Owner

@NemoDacremont commented on GitHub (Apr 3, 2025):

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

<!-- gh-comment-id:2774713249 --> @NemoDacremont commented on GitHub (Apr 3, 2025): 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
Author
Owner

@matze commented on GitHub (Apr 3, 2025):

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.

<!-- gh-comment-id:2774726304 --> @matze commented on GitHub (Apr 3, 2025): > 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.
Author
Owner

@NemoDacremont commented on GitHub (Apr 3, 2025):

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

<!-- gh-comment-id:2774760788 --> @NemoDacremont commented on GitHub (Apr 3, 2025): I'm currently going through the code, so I still don't know everything, but is it an issue ?
Author
Owner

@matze commented on GitHub (Apr 3, 2025):

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

<!-- gh-comment-id:2774764763 --> @matze commented on GitHub (Apr 3, 2025): It requires users to have Javascript enabled. So far, I tried to use JS only for sugar but not essential functionality.
Author
Owner

@NemoDacremont commented on GitHub (Apr 3, 2025):

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

<!-- gh-comment-id:2774768488 --> @NemoDacremont commented on GitHub (Apr 3, 2025): Oh ok it makes sense, I didn't get that and I kind of like the idea, isn't there any work around ?
Author
Owner

@matze commented on GitHub (Apr 3, 2025):

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.

<!-- gh-comment-id:2774770305 --> @matze commented on GitHub (Apr 3, 2025): 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](https://stackoverflow.com/questions/4526273/what-does-enctype-multipart-form-data-mean).
Author
Owner

@NemoDacremont commented on GitHub (Apr 3, 2025):

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

<!-- gh-comment-id:2774785044 --> @NemoDacremont commented on GitHub (Apr 3, 2025): If you want, I can try to add a PR and check if it works locally
Author
Owner

@matze commented on GitHub (Apr 3, 2025):

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

<!-- gh-comment-id:2774794870 --> @matze commented on GitHub (Apr 3, 2025): Try but please also add a test that breaks on the current behavior.
Author
Owner

@NemoDacremont commented on GitHub (Apr 3, 2025):

Yeah no problem, I'll try

<!-- gh-comment-id:2774810202 --> @NemoDacremont commented on GitHub (Apr 3, 2025): Yeah no problem, I'll try
Author
Owner

@NemoDacremont commented on GitHub (Apr 3, 2025):

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

<!-- gh-comment-id:2776083909 --> @NemoDacremont commented on GitHub (Apr 3, 2025): 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
Author
Owner

@matze commented on GitHub (Apr 3, 2025):

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

<!-- gh-comment-id:2776089130 --> @matze commented on GitHub (Apr 3, 2025): It should be possible to switch to the other encoding, I will give it a shot later tonight.
Author
Owner

@NemoDacremont commented on GitHub (Apr 3, 2025):

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

<!-- gh-comment-id:2776194497 --> @NemoDacremont commented on GitHub (Apr 3, 2025): 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
Author
Owner

@NemoDacremont commented on GitHub (Apr 13, 2025):

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 ?

<!-- gh-comment-id:2799951474 --> @NemoDacremont commented on GitHub (Apr 13, 2025): 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 ?
Author
Owner

@NemoDacremont commented on GitHub (Nov 4, 2025):

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

<!-- gh-comment-id:3484378356 --> @NemoDacremont commented on GitHub (Nov 4, 2025): As I closed my draft PR, I think there is no satisfying solution
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/wastebin-matze#90
No description provided.