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

[Ian Hickson]

On Wed, 29 Oct 2008, Michael A. Puls II wrote:
> 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:
> > > 
> > > 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%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.

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.   `._.-(,_..'--(,_..'`-.;.'