Pasted URLs process + characters improperly when they are used (properly) as spaces

AI-generated summary

MentalNomad reports a bug where pasted URLs in Discourse’s rich text editor improperly escape + characters (used as spaces in URL encoding) into %2B, breaking links to services like Frinklang. Examples show that both pasted URLs and those generated via Discourse’s hyperlink tool fail due to this misprocessing. MentalNomad notes this violates HTML form encoding standards (WHATWG spec). sam confirms the issue lies in the frontend and oneboxer, acknowledging its complexity due to historical bugs, and references a pending fix in PR #36822. MentalNomad adds context about Frinklang’s strict standards compliance and recommends it for scientific applications. The issue highlights how Discourse’s URL handling interferes with legitimate use of + as space in query strings.

Continuing the discussion from Pasted URLs in Rich Text Editor improperly escape tilde character:

Reproducing:

I entered the following URL above by pasting it in the editor:
https://frinklang.org/fsp/solve2.fsp?equations=a+%3D+3+b+%2B+c&solveFor=&f=&ev=on&sel_a=S&val_a=&sel_b=S&val_b=&sel_c=L&val_c=299792458+m+s%5E-1&resultAs=
Proper response to clicking on the link would be:

But the Discourse-Rendered version of that URL is:
https://frinklang.org/fsp/solve2.fsp?equations=a%2B%3D%2B3%2Bb%2B%2B%2Bc&solveFor=&f=&ev=on&sel_a=S&val_a=&sel_b=S&val_b=&sel_c=L&val_c=299792458%2Bm%2Bs%5E-1&resultAs=

Note the %2B replacing the + character. This fails, and produces the following result:

Testing hyperlink tool:

Discourse-Made-Hyperlink

Discourse Link Tool-Rendered URL:
https://frinklang.org/fsp/solve2.fsp?equations=a%2B%3D%2B3%2Bb%2B%2B%2Bc&solveFor=&f=&ev=on&sel_a=S&val_a=&sel_b=S&val_b=&sel_c=L&val_c=299792458%2Bm%2Bs%5E-1&resultAs=

This also fails, looking like this:

I’m not 100% sure what’s going wrong, but I think it’s the + characters, which should be spaces, being mis-processed into a literal +.

Using a + for a space in a URL is standards-compliant for HTML form encoding, so this is possibly affecting other sites/systems that use the + character this way.

See: WHATWG. HTML Living Standard. Section “URL-encoded form data”. HTML Standard

1 Like

Other issues which I thought were related, but I now think not:

https://github.com/discourse/discourse/pull/34834

Yeah this is a messy one, I think only the oneboxer and frontend bug:

https://frinklang.org/fsp/solve2.fsp?equations=a+%2B+b&solveFor=&f=&ev=on

vs:

<https://frinklang.org/fsp/solve2.fsp?equations=a+%2B+b&solveFor=&f=&ev=on>

vs:

https://frinklang.org/fsp/solve2.fsp?equations=a+%2B+b&solveFor=&f=&ev=on

I have a fix here, but as you can see from Related topics, this is VERY COMPLICATED :tm: , over the years there have been so many bugs in this area.

https://github.com/discourse/discourse/pull/36822

1 Like

Thanks for the attention!

You can trust Alan, the creator of the Frink language, to expose any error while being 100% standards-compliant. It’s what he does.

(Incidentally, if you ever need extreme unit correctness for any scientific or engineering application, do check out Frink.)

1 Like