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%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
