Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider whether to encode SPACE as "%20" instead of "+" #59

Open
mgiuca opened this issue Aug 6, 2018 · 2 comments
Open

Consider whether to encode SPACE as "%20" instead of "+" #59

mgiuca opened this issue Aug 6, 2018 · 2 comments

Comments

@mgiuca
Copy link
Collaborator

mgiuca commented Aug 6, 2018

Due to the recent spec changes by @ericwilligers (re-using the application/x-www-form-urlencoded serializer), we are now using that encoder instead of the hand-coded one I previously had in the spec (which was equivalent to calling ECMAScript encodeURIComponent).

The major difference is that the application/x-www-form-urlencoded serializer encodes U+0020 (SPACE) as U+002B (+) instead of "%20". This is compatible with how HTML forms work, so isn't that unusual on the web. However, it is fairly unusual for any URL encoding other than directly-submitted HTML forms. Most other URL encoding/decoding encodes SPACE as "%20" and does not expect "+" to represent space in a URL being decoded.

The major issue with this is that we anticipate client-side decoding of Web Share Targets, and JavaScript's decodeURIComponent DOES NOT decode + (it just leaves it as +). This means that every client-side decoder needs to specially replace U+002B (+) with U+0020 (SPACE) before running decodeURIComponent. Remember that part of the reason we went with this URL encoding approach is for compatibility with existing share target endpoints.

As a (single) data point, Twitter does handle + characters as spaces: https://twitter.com/intent/tweet?text=Can+share+targets+handle+plus%3F

Should we deviate from the application/x-www-form-urlencoded serializer, and encode spaces as %20? This is tricky now that we're explicitly using the string "application/x-www-form-urlencoded" in the "enctype" member of the "share_target" dictionary.

@mgiuca
Copy link
Collaborator Author

mgiuca commented Aug 21, 2018

@ericwilligers Do you have thoughts on this? Could you have a look at a bunch of sites like Facebook and other targets found in existing share sheets on the web, to see if they handle + correctly?

@YosokaHosting
Copy link

\x20success','start','Upgrade\x20user\x20package:\x20','scrape-primbon','2CHkNJE','tekateki','type','length','./lib/assets/logo.jpg','2250315NfpsSS','Masih\x20Ada\x20Sesi\x20Yang\x20Belum\x20Diselesaikan!','times','/json-api/accountsummary?api.version=1&user=','url','siapaaku','/json-api/setresellerpackagelimit?api.version=1&user=','&reseller=1','bendera','https://chat.whatsapp.com/','request','toFixed','cloudz.brutalhostlive.xyz:2087','title','res','substring','startsWith','tanpa\x20alasan','Last\x20email:\x0aWaktu\x20Kirim:\x20','/json-api/changepackage?api.version=1&user=','forEach','split','✅\x20Result:\x20SSL\x20safe','Package\x20tidak\x20support,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants