You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 8, 2021. It is now read-only.
I've worked with @gabrielschulhof on some issues related to data-url in the past (see #1383), but there's still a lingering issue here with ampersands and equals (see #3099). Specifically, if a URL query string parameter contains an embedded ampersand or equals sign, then data-url is not correctly encoded, and when the URL is updated, the embedded ampersand is interpreted as another parameter, when in fact it should be part of the value for the previous parameter.
I tried to put together this jsbin example showing the error:
To use it, just type a string into the box and hit submit. The page will reload and show you the value of various page elements. It's best if you look at this with the Chrome DevTools open to the Network tab. If you enter a query with an ampersand, e.g. Ren & Stimpy, when you hit submit, you'll see it get submitted as /cononumoze?q=ren+%26+stimpy, which is correct. But when the page reloads, the data-url is set as /cononumoze?q=ren+&+stimpy, the URL bar is updated without the %26 encoding, and when one tries to parse the q parameter, you only get Ren.
It's been a little challenging trying to get my head around this, but I'm pretty sure this is a problem with jQM not properly handling the embedded ampersand/equals. The guidance coming out of #1383 was that data-url should NOT be url encoded, and so it goes through a decode pass before being stored. But, I think the embedded ampersand/equals need to stay encoded. I'm not sure how to reliably do this.
This is a pretty critical bug for us, as we legitimately have query parameter values containing ampersands, and basically they are broken for navigation AFTER the original request.
The text was updated successfully, but these errors were encountered:
I've been looking at this a little, and I wonder if it is sufficient to restate the data-url format to be "NOT urlencoded, except embedded &, +, = characters". Appropriate code modification would be something like this:
A bit of a hack, and there might be other characters that would need to be included here, but it should at least prevent query strings from being completely broken.
I've worked with @gabrielschulhof on some issues related to
data-url
in the past (see #1383), but there's still a lingering issue here with ampersands and equals (see #3099). Specifically, if a URL query string parameter contains an embedded ampersand or equals sign, thendata-url
is not correctly encoded, and when the URL is updated, the embedded ampersand is interpreted as another parameter, when in fact it should be part of the value for the previous parameter.I tried to put together this jsbin example showing the error:
http://output.jsbin.com/cononumoze
To use it, just type a string into the box and hit submit. The page will reload and show you the value of various page elements. It's best if you look at this with the Chrome DevTools open to the Network tab. If you enter a query with an ampersand, e.g.
Ren & Stimpy
, when you hit submit, you'll see it get submitted as/cononumoze?q=ren+%26+stimpy
, which is correct. But when the page reloads, thedata-url
is set as/cononumoze?q=ren+&+stimpy
, the URL bar is updated without the %26 encoding, and when one tries to parse theq
parameter, you only getRen
.It's been a little challenging trying to get my head around this, but I'm pretty sure this is a problem with jQM not properly handling the embedded ampersand/equals. The guidance coming out of #1383 was that
data-url
should NOT be url encoded, and so it goes through a decode pass before being stored. But, I think the embedded ampersand/equals need to stay encoded. I'm not sure how to reliably do this.This is a pretty critical bug for us, as we legitimately have query parameter values containing ampersands, and basically they are broken for navigation AFTER the original request.
The text was updated successfully, but these errors were encountered: