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

[Michael A. Puls II]

On Tue, 02 Dec 2008 07:16:51 -0500, Ian Hickson <ian at hixie.ch> 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=mailto&url=%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="GET"><input 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