[whatwg] [WF2] action="mailto:" - encoding spaces

[Michael A. Puls II]

On Wed, 29 Oct 2008 03:42:17 -0400, Ian Hickson <ian at hixie.ch> 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%2B2&body=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+2&body=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