14555 2007-07-07 13:27:26 -0700 Spaces should be encoded as %20 in mailto URLs 2023-09-20 02:26:24 -0700 1 1 1 Unclassified WebKit Forms 523.x (Safari 3) All All NEW P3 Enhancement --- 37641 1 shadow2531 webkit-unassigned abarth ahmad.saleem792 annevk ap duerst edwardjsabol oldest_to_newest 5200 0 shadow2531 2007-07-07 13:27:26 -0700 When generating the encoded data set for an action="mailto:" form, a few things go wrong. 1. Values from the form fields are encoded twice. For example, with <input type="text" name="cc" value="test@site.com">, test@site.com will be encoded to test%2540site.com instead of just test%40site.com. 2. "body=" is inserted at the beginning of the data set, which causes other parts to become part of the body. 3. Spaces in the form fields are encoded to + instead of %20. Mail clients don't decode + to a space, so each space in the form fields will show up as + in the mail client. 5201 1 15436 shadow2531 2007-07-07 13:28:13 -0700 Created attachment 15436 Descriptive TC. (Will need to minimalize) 5214 2 ddkilzer 2007-07-07 14:38:41 -0700 This occurs with a local debug build of WebKit r24089 with Safari 3.0 (522.12) on Mac OS X 10.4.10 (8R218). It also occurs with Safari 2.0.4 (419.3) with original WebKit on Mac OS X 10.4.10. Note that Mail.app correctly parses the body out of the URL (unlike on Windows?), but everything is still improperly twice-encoded. 66046 3 ap 2008-01-02 09:40:57 -0800 Fixed (1) and (2) in <http://trac.webkit.org/projects/webkit/changeset/29086>. Since other browsers do not seem to encode spaces as suggested in (3), I have left this for later. The test case mentions efforts to get specs corrected - have those been successful? Also, is there a Firefox bug for (3)? Re-titling and changing priority to match the current scope of the bug. 66094 4 shadow2531 2008-01-02 17:59:23 -0800 (In reply to comment #3) > Fixed (1) and (2) in <http://trac.webkit.org/projects/webkit/changeset/29086>. Thanks > Since other browsers do not seem to encode spaces as suggested in (3), I have > left this for later. The test case mentions efforts to get specs corrected - > have those been successful? Also, is there a Firefox bug for (3)? The issue raised at < http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-January/009210.html > and < http://lists.w3.org/Archives/Public/public-html/2007May/1061.html > is still not resolved in HTML5 yet because the WebForms part of the spec hasn't been reviewed and put into HTML5. The editor of Xforms has also seen those links. No one really has given any feedback yet though. I've also mentioned this issue to the authors of RFC2368. They at least recognize the problem and believe that it's unfortunate that application/x-www-form-urlencoded uses '+' for spaces instead of %20. For this issue I've suggested clarifications in the replacement for RFC2368 < http://tools.ietf.org/html/draft-duerst-mailto-bis-03 >, but it has expired and I have not seen anything come of that yet. Instead, I've been making my own < http://shadow2531.com/opera/testcases/mailto/modern_mailto_uri_scheme.html >, which adresses this in the encoding section and in the forms section (which needs more work, but has a js example of what Firefox does for both GET and POST with action="mailto:" with an included fix for encoding spaces as %20). I don't think there's a Mozilla bug on this, but I'm pretty sure those in the HTML working group from Mozilla have seen the HTML5 posts above. I did file an Opera bug though, but forms in Opera with action="mailto:" are still partially broken, so what Opera does for #3 will have to wait till forms with action="mailto:" are fixed in general. For method="post" and action="mailto:", it might not make sense, but for method="get" and action="mailto:", it makes sense for sure to generate spaces as %20 instead of +. (You can easily see how things break when spaces are generated as + instead of %20 like they are now.) However, you are right, other browsers don't get it right either. So, I guess we must wait. 66178 5 duerst 2008-01-03 22:56:42 -0800 (In reply to comment #3) > Since other browsers do not seem to encode spaces as suggested in (3), I have > left this for later. The test case mentions efforts to get specs corrected - > have those been successful? Also, is there a Firefox bug for (3)? I have just published http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-04.txt, intended to obsolete RFC 2368. I made it clear that spaces in mailto URIs have to be escaped as %20, not as +. 271905 6 duerst 2010-08-30 21:15:56 -0700 (In reply to comment #5) > I have just published http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-04.txt, intended to obsolete RFC 2368. I made it clear that spaces in mailto URIs have to be escaped as %20, not as +. The above link doesn't work anymore, sorry. Please see https://datatracker.ietf.org/doc/draft-duerst-mailto-bis/. This draft has been approved by the IESG, and is now being worked on by the RFC Editor. 271907 7 duerst 2010-08-30 21:18:51 -0700 (In reply to comment #4) > However, you are right, other browsers don't get it right either. So, I guess we must wait. I don't understand why you want to wait for other browsers to fix something before you fix yourself. It may make sense when "being liberal in what you accept". But it doesn't make sense here, where the browser produces something, and it's other software (mailers) that accept it (or not). 271909 8 abarth 2010-08-30 21:21:38 -0700 It's unclear whether we want to support syntax like the following: mailto:addr1@an.example,addr2@an.example The situation requires further study. 271916 9 abarth 2010-08-30 21:35:52 -0700 Sorry, looks like bugzilla ate the example. 272014 10 shadow2531 2010-08-31 03:28:10 -0700 (In reply to comment #7) > (In reply to comment #4) > > > However, you are right, other browsers don't get it right either. So, I guess we must wait. > > I don't understand why you want to wait for other browsers to fix something before you fix yourself. It may make sense when "being liberal in what you accept". But it doesn't make sense here, where the browser produces something, and it's other software (mailers) that accept it (or not). I was just being patient etc. What I really think is that we should forget about what other browsers do and just do what makes sense and what makes sense is encoding spaces as %20. This is supported by <https://datatracker.ietf.org/doc/draft-duerst-mailto-bis/>. This is also supported by HTML5 <http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#submit-mailto-headers> for GET, PUT and DELETE, but not POST. Hixie didn't spec this for a POST dataset though because the whole dataset gets percent-encoded and becomes the body value, so it's not needed. And, if authors decide to use + in @action, it's their fault for not using %20 if they want a space and '%2B' if the want a '+' and things don't come out right in the client (local or http). See: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-January/009210.html> <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016858.html> <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-December/017667.html> But one certain thing was determined: Regardless of how browsers generate action=mailto: form data, they must convert that data to the format the client they're passing to understands. For example, if Thunderbird doesn't treat '+' as spaces (which it doesn't of course), then the browser should use %20 for spaces. What this means is that you can fix things with regex if you really wanted to with these rules: 1. Replace all '+' in @action with '%2B' before you do anything else (raw spaces should already be converted to %20 by the resolver). (In a copy of the @action value that you'll be working with. Don't modify the attribute's value.) 2. For method="not post", replace all '+' in the generated dataset with '%20" Then, everything's good to go and you don't have to modify the form dataset generation code to make an exception for 'mailto'. You can just do the "mailto:" stuff after the fact when @action contains a mailto URI. With that said, I see no reason to wait on anything to fix this. 272017 11 shadow2531 2010-08-31 03:30:31 -0700 > regex Would be overkill. I meant a simple replacement function. 272225 12 abarth 2010-08-31 11:21:28 -0700 > What I really think is that we should forget about what other browsers do and just do what makes sense and what makes sense is encoding spaces as %20. This is supported by <https://datatracker.ietf.org/doc/draft-duerst-mailto-bis/>. As I said above, I haven't studied this issue in detail. However, in general, ignoring the behavior of other browsers is unwise. 273373 13 shadow2531 2010-09-02 06:49:21 -0700 (In reply to comment #12) > > What I really think is that we should forget about what other browsers do and just do what makes sense and what makes sense is encoding spaces as %20. This is supported by <https://datatracker.ietf.org/doc/draft-duerst-mailto-bis/>. > > As I said above, I haven't studied this issue in detail. However, in general, ignoring the behavior of other browsers is unwise. Understood. To clarify though: As far as method!="post" and method="post" with enctype="application/x-www-form-urlencoded" (the default enctype), <http://shadow2531.com/opera/testcases/mailto/mailtoform.js> is what HTML5 is proposing. Since browsers are broken and non-interoperable with each other, this feature currently can't be used or relied upon on the web very much. So, HTML5 specs a common ground of what browsers do and what makes sense for interoperability etc. There's only one line in there that's not part of HTML5 and it's my suggestion. But, ignoring my suggestion, implementing the rest would be like any HTML5 feature--Implement it and give feedback to the group. 289375 14 duerst 2010-10-04 20:58:35 -0700 The new version of the mailto: URI/IRI scheme spec is out now, RFC 6068. Please see http://tools.ietf.org/html/rfc6068. 15436 2007-07-07 13:28:13 -0700 2007-07-07 13:28:13 -0700 Descriptive TC. (Will need to minimalize) mailtogetform.html text/html 2643 shadow2531 PCFET0NUWVBFIGh0bWw+CjxodG1sPgogICAgPGhlYWQ+CiAgICAgICAgPHRpdGxlPmFjdGlvbj0i bWFpbHRvIiBHRVQgbWV0aG9kPC90aXRsZT4KICAgICAgICA8c3R5bGU+CiAgICAgICAgICAgIGlu cHV0LCB0ZXh0YXJlYSB7CiAgICAgICAgICAgICAgICBkaXNwbGF5OiBibG9jazsKICAgICAgICAg ICAgICAgIHdpZHRoOiA1MDBweDsKICAgICAgICAgICAgfQogICAgICAgICAgICB0ZXh0YXJlYSB7 CiAgICAgICAgICAgICAgICBoZWlnaHQ6IDIwMHB4OwogICAgICAgICAgICB9CiAgICAgICAgICAg IGxpIHsKICAgICAgICAgICAgICAgIHBhZGRpbmc6IDVweDsKICAgICAgICAgICAgfQogICAgICAg IDwvc3R5bGU+CiAgICA8L2hlYWQ+CiAgICA8Ym9keT4KICAgICAgICA8aDE+YWN0aW9uPSJtYWls dG8iICsgbWV0aG9kPSJnZXQiPC9oMT4KICAgICAgICA8cD5TdWJtaXR0aW5nIHRoZSBmb2xsb3dp bmcgZm9ybSBzaG91bGQgZ2VuZXJhdGUgdGhlIGZvbGxvd2luZyBtYWlsdG8gVVJJIGFuZCBpdCBz aG91bGQgYmUgcGFzc2VkIHRvIHRoZSBkZWZhdWx0IG1haWwgY2xpZW50LiAodGVzdCB3aXRoIFRo dW5kZXJiaXJkIDMuMCBhcyB0aGUgZGVmYXVsdCBtYWlsIGNsaWVudC4gSXQgaGFzIHRoZSBiZXN0 IG1haWx0byBVUkkgcGFyc2luZy4pPC9wPgogICAgICAgIDxwcmU+bWFpbHRvOj90bz10bzElNDBz aXRlLmNvbSUyQyUyMHRvMiU0MHNpdGUuY29tJTJDJTIwdG8zJTQwc2l0ZS5jb20mY2M9Y2MxJTQw c2l0ZS5jb20lMkMlMjBjYzIlNDBzaXRlLmNvbSUyQyUyMGNjMyU0MHNpdGUuY29tJmJjYz1iY2Mx JTQwc2l0ZS5jb20lMkMlMjBiY2MyJTQwc2l0ZS5jb20lMkMlMjBiY2MzJTQwc2l0ZS5jb20mc3Vi amVjdD1tJTIwJTI2JTIwbSZib2R5PWxpbmUxJTBEJTBBbGluZTIlMEQlMEFsaW5lMyUwRCUwQWxp bmU0PC9wcmU+CiAgICAgICAgPGZvcm0gYWN0aW9uPSJtYWlsdG86IiBtZXRob2Q9ImdldCI+CiAg ICAgICAgICAgIDxpbnB1dCBuYW1lPSJ0byIgdmFsdWU9InRvMUBzaXRlLmNvbSwgdG8yQHNpdGUu Y29tLCB0bzNAc2l0ZS5jb20iPgogICAgICAgICAgICA8aW5wdXQgbmFtZT0iY2MiIHZhbHVlPSJj YzFAc2l0ZS5jb20sIGNjMkBzaXRlLmNvbSwgY2MzQHNpdGUuY29tIj4KICAgICAgICAgICAgPGlu cHV0IG5hbWU9ImJjYyIgdmFsdWU9ImJjYzFAc2l0ZS5jb20sIGJjYzJAc2l0ZS5jb20sIGJjYzNA c2l0ZS5jb20iPgogICAgICAgICAgICA8aW5wdXQgbmFtZT0ic3ViamVjdCIgdmFsdWU9Im0gJmFt cDsgbSI+Cjx0ZXh0YXJlYSBuYW1lPSJib2R5Ij5saW5lMQpsaW5lMgpsaW5lMwpsaW5lNDwvdGV4 dGFyZWE+CiAgICAgICAgICAgIDxpbnB1dCB0eXBlPSJzdWJtaXQiIHZhbHVlPSJDb21wb3NlIj4K ICAgICAgICA8L2Zvcm0+CiAgICAgICAgPHA+SG93ZXZlciwgdGhlIGZvbGxvd2luZyBtYWlsdG8g VVJJIGlzIGdlbmVyYXRlZCBpbnN0ZWFkLjwvcD4KICAgICAgICA8cHJlPm1haWx0bzo/Ym9keT10 bz10bzElMjU0MHNpdGUuY29tJTI1MkMrdG8yJTI1NDBzaXRlLmNvbSUyNTJDK3RvMyUyNTQwc2l0 ZS5jb20mY2M9Y2MxJTI1NDBzaXRlLmNvbSUyNTJDK2NjMiUyNTQwc2l0ZS5jb20lMjUyQytjYzMl MjU0MHNpdGUuY29tJmJjYz1iY2MxJTI1NDBzaXRlLmNvbSUyNTJDK2JjYzIlMjU0MHNpdGUuY29t JTI1MkMrYmNjMyUyNTQwc2l0ZS5jb20mc3ViamVjdD1tKyUyNTI2K20mYm9keT1saW5lMSUyNTBE JTI1MEFsaW5lMiUyNTBEJTI1MEFsaW5lMyUyNTBEJTI1MEFsaW5lNDwvcHJlPgogICAgICAgIDx1 bD4KICAgICAgICAgICAgPGxpPlRoZSBib2R5PSBhdCB0aGUgYmVnaW5uaW5nIHNob3VsZCBub3Qg YmUgdGhlcmUuPC9saT4KICAgICAgICAgICAgPGxpPlRoZSBodmFsdWVzIGFyZSBlbmNvZGVkIHR3 aWNlLiBGb3IgZXhhbXBsZSwgdG8xQHNpdGUuY29tIGlzIGVuY29kZWQgdG8gdG8xJTQwc2l0ZS5j b20sIHdoaWNoIGlzIGNvcnJlY3QsIGJ1dCB0aGVuIGl0IGlzIGVuY29kZWQgYWdhaW4gdG8gdG8x JTI1NDAuc2l0ZS5jb20sIHdoaWNoIGlzIG5vdCBjb3JyZWN0LjwvbGk+CiAgICAgICAgICAgIDxs aT5TcGFjZXMgZnJvbSB0aGUgZmllbGRzIGFyZSBlbmNvZGVkIHRvICsgaW5zdGVhZCBvZiAlMjAu IFRoaXMgaXMgZmluZSBmb3IgaHR0cCwgYnV0IGZvciBtYWlsdG8gVVJJcyBpdCBzaG91bGQgYmUg JTIwIGFzIG1haWx0byBjbGllbnRzIGRvbid0IGRlY29kZSArIHRvIGEgc3BhY2UuIE90aGVyIGJy b3dzZXJzIGhhdmUgdGhpcyBwcm9ibGVtIGFsc28gdGhvdWdoIGFuZCB0aGUgaXNzdWUgaGFzIGJl ZW4gcG9zdGVkIG9uIDxhIGhyZWY9Imh0dHA6Ly9saXN0cy53aGF0d2cub3JnL2h0ZGlnLmNnaS93 aGF0d2ctd2hhdHdnLm9yZy8yMDA3LUphbnVhcnkvMDA5MjEwLmh0bWwiPldIQVRXRzwvYT4gYW5k IDxhIGhyZWY9Imh0dHA6Ly9saXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy1odG1s LzIwMDdNYXkvMTA2MS5odG1sIj5wdWJsaWMtaHRtbDwvYT4uIChPcGVyYSdzIGFjdGlvbj0ibWFp bHRvOiIgaXMgYnJva2VuLCBzbyBubyBjb21wYXJpc29uIGNhbiBiZSBtYWRlIHdpdGggaXQsIGJ1 dCB5b3UgY2FuIGNvbXBhcmUgd2l0aCBGaXJlZm94IGFuZCBJRS4pPC9saT4KICAgICAgICA8L3Vs PgogICAgPC9ib2R5Pgo8L2h0bWw+