mirror of
https://github.com/matze/wastebin.git
synced 2026-04-25 08:36:00 +03:00
[GH-ISSUE #148] extra CR characters when I send a paste #90
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/wastebin-matze#90
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 :
How to Reproduce?
\nas line separator to wastebin (or just copy paste) :which is in hex format :
We can see there is extra characters
0x0dbefore the0x0a(\n)@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
@matze commented on GitHub (Apr 3, 2025):
Which would mean using the JSON API to POST the data. Hmm … wanted to avoid that to be honest.
@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 ?
@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.
@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 ?
@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.
@NemoDacremont commented on GitHub (Apr 3, 2025):
If you want, I can try to add a PR and check if it works locally
@matze commented on GitHub (Apr 3, 2025):
Try but please also add a test that breaks on the current behavior.
@NemoDacremont commented on GitHub (Apr 3, 2025):
Yeah no problem, I'll try
@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
@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.
@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
@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 ?
@NemoDacremont commented on GitHub (Nov 4, 2025):
As I closed my draft PR, I think there is no satisfying solution