Re: [whatwg] [WF2] action=mailto: - encoding spaces
Ian Hickson wrote: ... I actually can't find where it is defined that the + in an HTTP URI represents a space. (I can find where it says that a space is to be converted into a +, but not the other way around.) Where does it say that? Surely not RFC 2616? RFC 3986? My understanding, though, is that the convention that + represents a space is not part of the URI syntax, but part of the syntax of the format used to encode the data into the URI, which for HTTP URIs is generally application/x-www-form-urlencoded. But nothing stops this format from Yes: http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1 being used elsewhere, e.g. in the body of an e-mail or a POST submission. I could be used, but I'm not sure it should. What's the advantage over representing SP as %20? ... BR, Julian
Re: [whatwg] [WF2] action=mailto: - encoding spaces
On Tue, 02 Dec 2008 05:00:11 -0500, Ian Hickson [EMAIL PROTECTED] wrote:
On Tue, 2 Dec 2008, Michael A. Puls II wrote:
Consider this form:
form action=mailto:?subject=1+2; action=POST
input type=submit value=Compose
/form
(which contains a valid mailto URI meaning that 1+2 should be the
value of the subject)
Imagine in your browser that it supports setting the default mailto URI
handler to Gmail (a web-based client that uses *http* URIs).
If you submit that form, you'd get
https://mail.google.com/mail/?compose=1view=cmfs=1su=1+2
Why? How so?
Are you referring to the registerProtocolHandler() API, to mailto: form
submission, or to something else?
Thanks
I'm talking about a UA associating mailto: links and mailto: form submission
with webmail clients (like Gmail for example) by whatever means, just like UAs
can do with Thunderbird for example.
This could be done with registerProtocolHandler, but the webmail would have to
accept a uri= in its compose URI query string and the function (at least the
internal one) couldn't be domain-restricted.
Gmail (and most webmails) currently don't support a uri=, but I have a specific
proposal for Gmail if I can find someone to submit it to.
To support Gmail now, registerProtocolHandler would have to be like:
registerProtocolHandler(mailto, function(e) {
var uri = e.uri;
// parse the URI to get the individual to, cc, bcc, subject and body hvalues
// and use them to build a Gmail compose URI
// Plus, escapeUnsafe and invalid characters and %HH
// Plus, join multiple occurences of an hvalue
// using a different algorithm depending on
// the type of hvalue.
}, Compose in Gmail?);
Anyway, goto
http://shadow2531.com/opera/testcases/mailto/register_protocol_handler.html
and click on the first link. If Gmail worked like that, it could totally work around
the '+' issue and support a registerProtocolHandler-like function. Of course, Gmail
could simply not decode + to ' ' for its to, cc, bcc, body and su hvalues that it
currently supports. Then though, there'd still be a bunch of other webmails that'd
need to do it also. But, take a look at the source of the pages and the included JS.
They show the things that are necessary to implement parsing in a compatible way and
will help with your following question.
Could you lay out the steps that take us from a form submission using a
mailto: URL to an HTTPS request to GMail?
Maybe this will help:
Download http://shadow2531.com/opera/userjs/BeforeMailtoURL.js to a folder.
Edit it and set supportForms to true.
In Opera, goto tools - preferences - advanced - content - javascript
options and set your UserJS folder to the folder BeforeMailtoURL.js is in.
Log in to http://mail.google.com/.
Goto http://shadow2531.com/opera/testcases/mailto/003-post.html and
http://shadow2531.com/opera/testcases/mailto/003.html and click compose.
In BeforeMailtoURL.js, you can look at createMailtoURIFromEnabledFormControls(form), if (supportForms),
the MailtoURIParser class and the format() function. And, look at the if (form.method == post) part to
see how I convert '+' to %2B in the action attribute to avoid this problem. (Note that the way I parse the form isn't
complete. Wish: Forms should have a generateDataset() so UAs can do if for you.)
Checking
http://shadow2531.com/opera/testcases/mailto/modern_mailto_uri_scheme.html#forms
and the whole page might help too.
But, basically, with webmail clients, you have to be careful and encode '+' as
%2B in all parts of the submitted mailto data, including parts that come from
the action attribute.
So, as a suggestion:
On the authoring side, making form action=mailto:?subject=1+2; method=post invalid and form
action=mailto:?subject=1%2B2; method=post valid would help.
On a handling side for mailto:;, saying the UA should convert the + to %2B
*if* the submitted data will end up in an http URI, might help. This is good because I
believe UAs will do this regardless of the spec if they need to support Webmails. Having
it specified or hinted at though would be nice.
--
Michael
Re: [whatwg] [WF2] action=mailto: - encoding spaces
On Tue, 2 Dec 2008, Michael A. Puls II wrote: Consider this form: form action=mailto:?subject=1+2; action=POST input type=submit value=Compose /form (which contains a valid mailto URI meaning that 1+2 should be the value of the subject) Imagine in your browser that it supports setting the default mailto URI handler to Gmail (a web-based client that uses *http* URIs). If you submit that form, you'd get https://mail.google.com/mail/?compose=1view=cmfs=1su=1+2 Why? How so? Are you referring to the registerProtocolHandler() API, to mailto: form submission, or to something else? Could you lay out the steps that take us from a form submission using a mailto: URL to an HTTPS request to GMail? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [WF2] action=mailto: - encoding spaces
On Tue, 2 Dec 2008, Michael A. Puls II wrote: I'm talking about a UA associating mailto: links and mailto: form submission with webmail clients (like Gmail for example) by whatever means, just like UAs can do with Thunderbird for example. This could be done with registerProtocolHandler, but the webmail would have to accept a uri= in its compose URI query string and the function (at least the internal one) couldn't be domain-restricted. Gmail (and most webmails) currently don't support a uri=, but I have a specific proposal for Gmail if I can find someone to submit it to. GMail supports registerProtocolHandler, just use: https://mail.google.com/mail/?extsrc=mailtourl=%s Anyway, goto http://shadow2531.com/opera/testcases/mailto/register_protocol_handler.html and click on the first link. If Gmail worked like that, it could totally work around the '+' issue and support a registerProtocolHandler-like function. Of course, Gmail could simply not decode + to ' ' for its to, cc, bcc, body and su hvalues that it currently supports. Then though, there'd still be a bunch of other webmails that'd need to do it also. But, take a look at the source of the pages and the included JS. They show the things that are necessary to implement parsing in a compatible way and will help with your following question. I'm very confused. registerProtocolHandler() says to escape the mailto: URL, so no + characters make it through. If a tool is processing a mailto: URL manually converting it to an HTTP URL, then it has to escape + characters too. Could you lay out the steps that take us from a form submission using a mailto: URL to an HTTPS request to GMail? Maybe this will help: Download http://shadow2531.com/opera/userjs/BeforeMailtoURL.js to a folder. Edit it and set supportForms to true. In Opera, goto tools - preferences - advanced - content - javascript options and set your UserJS folder to the folder BeforeMailtoURL.js is in. Log in to http://mail.google.com/. Goto http://shadow2531.com/opera/testcases/mailto/003-post.html and http://shadow2531.com/opera/testcases/mailto/003.html and click compose. In BeforeMailtoURL.js, you can look at createMailtoURIFromEnabledFormControls(form), if (supportForms), the MailtoURIParser class and the format() function. And, look at the if (form.method == post) part to see how I convert '+' to %2B in the action attribute to avoid this problem. (Note that the way I parse the form isn't complete. Wish: Forms should have a generateDataset() so UAs can do if for you.) Right, if you convert a mailto: URL to an http: URL, you have to convert the bytes to be in the right format. So what? That's not a bug, it's what happens when you have different semantics in different formats and you translate from one to another. So, as a suggestion: On the authoring side, making form action=mailto:?subject=1+2; method=post invalid and form action=mailto:?subject=1%2B2; method=post valid would help. That would be a change to the mailto: URL scheme, which is out of scope for HTML5. On a handling side for mailto:;, saying the UA should convert the + to %2B *if* the submitted data will end up in an http URI, might help. As far as I can tell, the spec already says that for all cases where this might happen. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [WF2] action=mailto: - encoding spaces
On Tue, 02 Dec 2008 02:48:15 -0500, Ian Hickson [EMAIL PROTECTED] wrote: On Wed, 29 Oct 2008, Michael A. Puls II wrote: On Wed, 29 Oct 2008 03:42:17 -0400, Ian Hickson [EMAIL PROTECTED] wrote: On Wed, 29 Oct 2008, Michael A. Puls II wrote: What about the method=POST case where the query string is kept? form action=mailto:?subject=1+2; method=POST input type=text name=body value=1+2 input type=text name=other value=1 2 input type=submit /form When submitting that, I expect to see: mailto:?subject=1%2B2body=body%3D1%252B2%26other%3D1%25202 submitted to the mail client. The current POST section seems to say that this would be submitted instead: mailto:?subject=1+2body=body%3D1%252B2%26other%3D1+2 In other words, I think spaces in values should be emitted as %20 for POST too and in the case there's a query string present in the action attribute for POST, any + in the hvalues of the query string should be normalized to %2B (to be consistent with a + inside a form control's value that gets converted to %2B) The idea is that the same thing as would be posted to an HTTP server is what is sent using the e-mail body, so I think we'd want the exact same + behavior as normally. O.K., but in the case of the + that's in the mailto URI in the action attribute, the author means a '+' and not a space (they're allowed to be left in raw form in a mailto URI). If it gets sent to a server, the + will be treated as a space, which is not what is intended. I actually can't find where it is defined that the + in an HTTP URI represents a space. (I can find where it says that a space is to be converted into a +, but not the other way around.) My understanding, though, is that the convention that + represents a space is not part of the URI syntax, but part of the syntax of the format used to encode the data into the URI, which for HTTP URIs is generally application/x-www-form-urlencoded. But nothing stops this format from being used elsewhere, e.g. in the body of an e-mail or a POST submission. The workaround is of course for the author to make sure to encode that + as %2B (or never use anything but action=mailto:; even for POST). But, for good measure, it seems like the UA should fix that if the + will ever end up in an HTTP URI. I don't follow. Of course right now, browsers only pass the data as a mailto URI to an email program, so the + from the query string will be a + and come out fine in the compose window. As for spaces in form control values coming out as + (for POST) in a programs's body field, that's not as big of a deal as there's no use-case to *see* any of the data *like that* anyway. But it does seem incorrect to encode mailto spaces as + though. I don't follow. However, if for POST, if everything after 'mailto:' in the action attribute was dropped (like get) and all you ever had was mailto:?body=encoded_stuff that was POSTed, then the spec could say that the value you might see in the body field represents *HTTP* url encoded data. We can't drop everything, because then you'd lost the Subject: line, etc. Or, the spec could say that if the protocol in the action attribute is mailto:, +s in the action attribute have to be encoded as %2B and spaces in the action attribute have to be encoded as %20. Then, the validator can catch that and the spec can say (for POST), that the body hvalue that gets generated from the form represents *HTTP* form data. Then, it'll be clear why +s in the value are represented as + instead of %20. I don't follow here either. Or, if it's O.K. for a UA's URI normalizer/resolver to take action=mailto:?subject=1+2 3 and normalize that to action=mailto:?subject=1%2B2%203; for use with the form's .action getter, I guess that might solve it to. I think we may be talking at cross-purposes... which requirements in the spec are you referring to? I'll try to explain more. Consider this form: form action=mailto:?subject=1+2; action=POST input type=submit value=Compose /form (which contains a valid mailto URI meaning that 1+2 should be the value of the subject) Imagine in your browser that it supports setting the default mailto URI handler to Gmail (a web-based client that uses *http* URIs). If you submit that form, you'd get https://mail.google.com/mail/?compose=1view=cmfs=1su=1+2 , which if you try, you'll see emits 1 2 instead of 1+2 in the subject field. Basically, HTML is trying to say that + is equal to , but mailto URI hnames and hvalues are not application/x-www-form-urlencoded. They're close, but have less reserved characters. So, the browser has to convert the + to %2B before submitting (because the value will end up in an http URI, in this case) to Gmail so the correct value ends up in the subject field. (This isn't a problem for non-web-based email clients because they don't treat hnames and hvalues in mailto URIs as application/x-www-form-urlencoded). If you specify
Re: [whatwg] [WF2] action=mailto: - encoding spaces
On Tue, 2 Dec 2008, Julian Reschke wrote: Ian Hickson wrote: ... I actually can't find where it is defined that the + in an HTTP URI represents a space. (I can find where it says that a space is to be converted into a +, but not the other way around.) Where does it say that? Surely not RFC 2616? RFC 3986? HTML4; you cited the exact reference below. My understanding, though, is that the convention that + represents a space is not part of the URI syntax, but part of the syntax of the format used to encode the data into the URI, which for HTTP URIs is generally application/x-www-form-urlencoded. But nothing stops this format from Yes: http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1 being used elsewhere, e.g. in the body of an e-mail or a POST submission. I could be used, but I'm not sure it should. What's the advantage over representing SP as %20? None whatsoever, as far as I can tell. That's why people normally use text/plain. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [WF2] action=mailto: - encoding spaces
On Tue, 02 Dec 2008 07:16:51 -0500, Ian Hickson [EMAIL PROTECTED] wrote: On Tue, 2 Dec 2008, Michael A. Puls II wrote: I'm talking about a UA associating mailto: links and mailto: form submission with webmail clients (like Gmail for example) by whatever means, just like UAs can do with Thunderbird for example. This could be done with registerProtocolHandler, but the webmail would have to accept a uri= in its compose URI query string and the function (at least the internal one) couldn't be domain-restricted. Gmail (and most webmails) currently don't support a uri=, but I have a specific proposal for Gmail if I can find someone to submit it to. GMail supports registerProtocolHandler, just use: https://mail.google.com/mail/?extsrc=mailtourl=%s Cool thanks. Anyway, goto http://shadow2531.com/opera/testcases/mailto/register_protocol_handler.html and click on the first link. If Gmail worked like that, it could totally work around the '+' issue and support a registerProtocolHandler-like function. Of course, Gmail could simply not decode + to ' ' for its to, cc, bcc, body and su hvalues that it currently supports. Then though, there'd still be a bunch of other webmails that'd need to do it also. But, take a look at the source of the pages and the included JS. They show the things that are necessary to implement parsing in a compatible way and will help with your following question. I'm very confused. registerProtocolHandler() says to escape the mailto: URL, so no + characters make it through. That's what I was saying. If a tool is processing a mailto: URL manually converting it to an HTTP URL, then it has to escape + characters too. Could you lay out the steps that take us from a form submission using a mailto: URL to an HTTPS request to GMail? Maybe this will help: Download http://shadow2531.com/opera/userjs/BeforeMailtoURL.js to a folder. Edit it and set supportForms to true. In Opera, goto tools - preferences - advanced - content - javascript options and set your UserJS folder to the folder BeforeMailtoURL.js is in. Log in to http://mail.google.com/. Goto http://shadow2531.com/opera/testcases/mailto/003-post.html and http://shadow2531.com/opera/testcases/mailto/003.html and click compose. In BeforeMailtoURL.js, you can look at createMailtoURIFromEnabledFormControls(form), if (supportForms), the MailtoURIParser class and the format() function. And, look at the if (form.method == post) part to see how I convert '+' to %2B in the action attribute to avoid this problem. (Note that the way I parse the form isn't complete. Wish: Forms should have a generateDataset() so UAs can do if for you.) Right, if you convert a mailto: URL to an http: URL, you have to convert the bytes to be in the right format. So what? That's not a bug, it's what happens when you have different semantics in different formats and you translate from one to another. What I'm saying is that in this case, I shouldn't have to convert '+' to '%2B'. It should be part of of action attribute normalization so that it matches how control values are encoded. Basically, I was looking for consistency here. For mailto: form action=mailto:?subject=1+2; method=POST/form should be like form action=mailto:; method=GETinput name=subject value=1+2/form in this case, where 1%2B2 is emitted for subject. Converting '+' to %2B in the action attribute of the POST example doesn't violate the mailto URI spec any more than converting the '+' in the GET example to %2B. But, since this can be avoided on the authoring side and on the implementation side, I'll leave it at that. Thanks -- Michael
Re: [whatwg] [WF2] action=mailto: - encoding spaces
On Wed, 29 Oct 2008, Michael A. Puls II wrote: On Wed, 29 Oct 2008 03:42:17 -0400, Ian Hickson [EMAIL PROTECTED] wrote: On Wed, 29 Oct 2008, Michael A. Puls II wrote: What about the method=POST case where the query string is kept? form action=mailto:?subject=1+2; method=POST input type=text name=body value=1+2 input type=text name=other value=1 2 input type=submit /form When submitting that, I expect to see: mailto:?subject=1%2B2body=body%3D1%252B2%26other%3D1%25202 submitted to the mail client. The current POST section seems to say that this would be submitted instead: mailto:?subject=1+2body=body%3D1%252B2%26other%3D1+2 In other words, I think spaces in values should be emitted as %20 for POST too and in the case there's a query string present in the action attribute for POST, any + in the hvalues of the query string should be normalized to %2B (to be consistent with a + inside a form control's value that gets converted to %2B) The idea is that the same thing as would be posted to an HTTP server is what is sent using the e-mail body, so I think we'd want the exact same + behavior as normally. O.K., but in the case of the + that's in the mailto URI in the action attribute, the author means a '+' and not a space (they're allowed to be left in raw form in a mailto URI). If it gets sent to a server, the + will be treated as a space, which is not what is intended. I actually can't find where it is defined that the + in an HTTP URI represents a space. (I can find where it says that a space is to be converted into a +, but not the other way around.) My understanding, though, is that the convention that + represents a space is not part of the URI syntax, but part of the syntax of the format used to encode the data into the URI, which for HTTP URIs is generally application/x-www-form-urlencoded. But nothing stops this format from being used elsewhere, e.g. in the body of an e-mail or a POST submission. The workaround is of course for the author to make sure to encode that + as %2B (or never use anything but action=mailto:; even for POST). But, for good measure, it seems like the UA should fix that if the + will ever end up in an HTTP URI. I don't follow. Of course right now, browsers only pass the data as a mailto URI to an email program, so the + from the query string will be a + and come out fine in the compose window. As for spaces in form control values coming out as + (for POST) in a programs's body field, that's not as big of a deal as there's no use-case to *see* any of the data *like that* anyway. But it does seem incorrect to encode mailto spaces as + though. I don't follow. However, if for POST, if everything after 'mailto:' in the action attribute was dropped (like get) and all you ever had was mailto:?body=encoded_stuff that was POSTed, then the spec could say that the value you might see in the body field represents *HTTP* url encoded data. We can't drop everything, because then you'd lost the Subject: line, etc. Or, the spec could say that if the protocol in the action attribute is mailto:, +s in the action attribute have to be encoded as %2B and spaces in the action attribute have to be encoded as %20. Then, the validator can catch that and the spec can say (for POST), that the body hvalue that gets generated from the form represents *HTTP* form data. Then, it'll be clear why +s in the value are represented as + instead of %20. I don't follow here either. Or, if it's O.K. for a UA's URI normalizer/resolver to take action=mailto:?subject=1+2 3 and normalize that to action=mailto:?subject=1%2B2%203; for use with the form's .action getter, I guess that might solve it to. I think we may be talking at cross-purposes... which requirements in the spec are you referring to? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [WF2] action=mailto: - encoding spaces
On Tue, 28 Oct 2008 16:01:33 -0400, Ian Hickson [EMAIL PROTECTED] wrote: On Tue, 30 Jan 2007, Shadow2531 wrote: http://www.whatwg.org/specs/web-forms/current-work/#for-mailto http://www.whatwg.org/specs/web-forms/current-work/#x-www-form-urlencoded (#4) In mailto URIs, %20 represents a space. form action=mailto:; input name=subject value=1 2 input type=submit /form If you submit that form, mailto:?subject=1+2; will be passed to the mail client instead of mailto:?subject=1%202;. This results in 1+2 in the subject field instead of 1 2. Are UAs allowed to use %20 instead so things come out right, or must mail clients decode + to a space? Thunderbird, M2, and Outlook express don't decode +s. RFC2368 is referenced, but it and application/x-www-form-urlencoded that the mailto: form methods are referenced under conflict with each other on whether a space should be encoded to %20 or +. Fixed in the HTML5 spec. Thanks. Awesome! Thanks. Question though. What about the method=POST case where the query string is kept? For example: form action=mailto:?subject=1+2; method=POST input type=text name=body value=1+2 input type=text name=other value=1 2 input type=submit /form When submitting that, I expect to see: mailto:?subject=1%2B2body=body%3D1%252B2%26other%3D1%25202 submitted to the mail client. The current POST section seems to say that this would be submitted instead: mailto:?subject=1+2body=body%3D1%252B2%26other%3D1+2 In other words, I think spaces in values should be emitted as %20 for POST too and in the case there's a query string present in the action attribute for POST, any + in the hvalues of the query string should be normalized to %2B (to be consistent with a + inside a form control's value that gets converted to %2B) Also, for POST only, if there isn't a subject hvalue specified in the action attribute, Firefox will append subject=Form%20Post%20from%20Firefox so that Form Post from Firefox ends up in the mail client's subject field. Do you think Form Post from UA should be specified? -- Michael
Re: [whatwg] [WF2] action=mailto: - encoding spaces
On Wed, 29 Oct 2008, Michael A. Puls II wrote: Question though. What about the method=POST case where the query string is kept? For example: form action=mailto:?subject=1+2; method=POST input type=text name=body value=1+2 input type=text name=other value=1 2 input type=submit /form When submitting that, I expect to see: mailto:?subject=1%2B2body=body%3D1%252B2%26other%3D1%25202 submitted to the mail client. The current POST section seems to say that this would be submitted instead: mailto:?subject=1+2body=body%3D1%252B2%26other%3D1+2 In other words, I think spaces in values should be emitted as %20 for POST too and in the case there's a query string present in the action attribute for POST, any + in the hvalues of the query string should be normalized to %2B (to be consistent with a + inside a form control's value that gets converted to %2B) The idea is that the same thing as would be posted to an HTTP server is what is sent using the e-mail body, so I think we'd want the exact same + behavior as normally. Also, for POST only, if there isn't a subject hvalue specified in the action attribute, Firefox will append subject=Form%20Post%20from%20Firefox so that Form Post from Firefox ends up in the mail client's subject field. Do you think Form Post from UA should be specified? I don't think that's really necessary; UAs are free to implement e-mails however they like really. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [WF2] action=mailto: - encoding spaces
On Wed, 29 Oct 2008 03:42:17 -0400, Ian Hickson [EMAIL PROTECTED] wrote: On Wed, 29 Oct 2008, Michael A. Puls II wrote: Question though. What about the method=POST case where the query string is kept? For example: form action=mailto:?subject=1+2; method=POST input type=text name=body value=1+2 input type=text name=other value=1 2 input type=submit /form When submitting that, I expect to see: mailto:?subject=1%2B2body=body%3D1%252B2%26other%3D1%25202 submitted to the mail client. The current POST section seems to say that this would be submitted instead: mailto:?subject=1+2body=body%3D1%252B2%26other%3D1+2 In other words, I think spaces in values should be emitted as %20 for POST too and in the case there's a query string present in the action attribute for POST, any + in the hvalues of the query string should be normalized to %2B (to be consistent with a + inside a form control's value that gets converted to %2B) The idea is that the same thing as would be posted to an HTTP server is what is sent using the e-mail body, so I think we'd want the exact same + behavior as normally. O.K., but in the case of the + that's in the mailto URI in the action attribute, the author means a '+' and not a space (they're allowed to be left in raw form in a mailto URI). If it gets sent to a server, the + will be treated as a space, which is not what is intended. The workaround is of course for the author to make sure to encode that + as %2B (or never use anything but action=mailto:; even for POST). But, for good measure, it seems like the UA should fix that if the + will ever end up in an HTTP URI. Of course right now, browsers only pass the data as a mailto URI to an email program, so the + from the query string will be a + and come out fine in the compose window. As for spaces in form control values coming out as + (for POST) in a programs's body field, that's not as big of a deal as there's no use-case to *see* any of the data *like that* anyway. But it does seem incorrect to encode mailto spaces as + though. However, if for POST, if everything after 'mailto:' in the action attribute was dropped (like get) and all you ever had was mailto:?body=encoded_stuff that was POSTed, then the spec could say that the value you might see in the body field represents *HTTP* url encoded data. Or, the spec could say that if the protocol in the action attribute is mailto:, +s in the action attribute have to be encoded as %2B and spaces in the action attribute have to be encoded as %20. Then, the validator can catch that and the spec can say (for POST), that the body hvalue that gets generated from the form represents *HTTP* form data. Then, it'll be clear why +s in the value are represented as + instead of %20. Or, if it's O.K. for a UA's URI normalizer/resolver to take action=mailto:?subject=1+2 3 and normalize that to action=mailto:?subject=1%2B2%203; for use with the form's .action getter, I guess that might solve it to. Of course, there's no use for POST and action=mailto:; right now, so I guess we have time to fix things later if they become a problem. Thanks On a side, if you look at the 'if (form.method == post)' condition in http://shadow2531.com/opera/userjs/BeforeMailtoURL.js, you'll see how I handle this. (The form dataset generation is not as complete as it should be though, but doing that seems complicated. Wish browsers had a form.generateDataset() function) -- Michael
Re: [whatwg] [WF2] action=mailto: - encoding spaces
On Tue, 30 Jan 2007, Shadow2531 wrote: http://www.whatwg.org/specs/web-forms/current-work/#for-mailto http://www.whatwg.org/specs/web-forms/current-work/#x-www-form-urlencoded (#4) In mailto URIs, %20 represents a space. form action=mailto:; input name=subject value=1 2 input type=submit /form If you submit that form, mailto:?subject=1+2; will be passed to the mail client instead of mailto:?subject=1%202;. This results in 1+2 in the subject field instead of 1 2. Are UAs allowed to use %20 instead so things come out right, or must mail clients decode + to a space? Thunderbird, M2, and Outlook express don't decode +s. RFC2368 is referenced, but it and application/x-www-form-urlencoded that the mailto: form methods are referenced under conflict with each other on whether a space should be encoded to %20 or +. Fixed in the HTML5 spec. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [WF2] action=mailto: - encoding spaces
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-January/009210.html This is now covered by the 3rd paragraph in http://tools.ietf.org/html/draft-duerst-mailto-bis-04#section-5 , which is to obsolete RFC2368. Spaces SHOULD be emitted as %20 and not +, in this case. This is covered in my notes http://shadow2531.com/opera/testcases/mailto/modern_mailto_uri_scheme.html also. -- Michael
[whatwg] [WF2] action=mailto: - encoding spaces
http://www.whatwg.org/specs/web-forms/current-work/#for-mailto http://www.whatwg.org/specs/web-forms/current-work/#x-www-form-urlencoded (#4) In mailto URIs, %20 represents a space. form action=mailto:; input name=subject value=1 2 input type=submit /form If you submit that form, mailto:?subject=1+2; will be passed to the mail client instead of mailto:?subject=1%202;. This results in 1+2 in the subject field instead of 1 2. Are UAs allowed to use %20 instead so things come out right, or must mail clients decode + to a space? Thunderbird, M2, and Outlook express don't decode +s. RFC2368 is referenced, but it and application/x-www-form-urlencoded that the mailto: form methods are referenced under conflict with each other on whether a space should be encoded to %20 or +. -- burnout426
