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
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.
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.
The text was updated successfully, but these errors were encountered:
@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?
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 runningdecodeURIComponent
. 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%3FShould 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.The text was updated successfully, but these errors were encountered: