[whatwg] [WF2] form submission protocols and methods

[Maciej Stachowiak]

On Dec 12, 2005, at 5:58 PM, Ian Hickson wrote:

>
>>> Note that user agents may implement whichever URI schemes are  
>>> required
>>> for their particular application. The WF2 specification does not
>>> specify a required core set of protocols that must be  
>>> implemented. For
>>> those that are implemented, UAs must use the algorithms given in
>>> section 5.6 when submitting data using those protocols, but for  
>>> those
>>> that aren't, the presence of the protocol in section 5.6 doesn't  
>>> imply
>>> the UA is non-conformant or anything.
>>
>> I think this could be made more clear.
>
> Heh. The above is almost word-for-word copied and pasted from the  
> spec.
> How would you recommend making it clearer?

All right, I missed this bit.

I'll comment on the file upload stuff later, in the meantime:

>>>> http: - "put" and "delete" are little-used methods on the web.
>>>
>>> Well, yeah, since there's basically no way to use them. This is  
>>> partly
>>> intended to address this.
>>
>> In theory you could use them through XMLHttpRequest, if that were
>> specified as allowed I think it would be more useful than allowing  
>> them
>> as form submission methods.
>
> That's specified as allowed already.

So you think they should be left in? It wouldn't be an unreasonable  
burden to implement these so I'm willing to withdraw my objection if  
no one else things it is a problem.

> It would be so cool to be able to implement an FTP client with just a
> simple HTML form. But ok. I've made them all act as GET.

Sounds good.

>
>
>>>> data: - all the methods except "get" seem weird and of questionable
>>>> usefulness. The things you can do through trivial text substitution
>>>> are extremely limited and are better handled by script IMO.
>>>
>>> So what should happen instead?
>>
>> Once again, treat as unknown method, i.e. like "get". I think  
>> there is a
>> mistaken desire to want to fill every box in the 3-D
>> protocol/format/method grid, but it seems more reasonable to me to  
>> treat
>> method as specific to protocol and for now only applicable to  
>> http, and
>> essentially ignore method for the other protocols.
>
> Fair enough for the other protocols, but in the case of data:, it  
> would
> actually be really useful from a debugging persective to be able to  
> get
> ahold of the form submission data. Given how easy the definition  
> for data:
> is to implement, do you still object to it?

No strong objection, although the usefulness of this behavior seems  
limited and it would have to be a special case in the code.

>> "Untrusted content" is unclear. It implies the existence of something
>> that isn't "untrusted content", i.e. "trusted content". Where is that
>> defined? I do not believe it is defined anywhere, in which case
>> specifying its behavior seems non-useful.
>
> I have rephrased this sentence.

I think this section is still somewhat problematic because a  
reasonable behavior is to allow "get" posts to "file:" URLs from a  
local file document that is not marked trusted in any special way, as  
such a document can already do normal "file:" URL loads anyway  
through other mechanisms. And this is much less risky than allowing  
execution of prgrams or writing/deleting of files.

However, ignoring the method in this case would put UAs in conflict  
with this non-normative section, so at minimum it seems they would  
have to change to disallow "post", "put" and "delete" entirely or be  
in conflict with this section. I'm not even sure if considering some  
content only "trusted" enough for one of the four columns would  
satisfy this section.

But this does not seem like a very serious problem, now that the  
section is non-normative.


>>>> mailto: - "post"/"put"/"delete" behavior seems useless, since  
>>>> the form
>>>> can control the body but not the headers (or at least the  
>>>> headers can't
>>>> come from form elements in any obvious way). It seems like in  
>>>> most cases
>>>> you'd want the body text to be composed text in any case -  
>>>> popping up a
>>>> message window full of form submission date does not seem useful. I
>>>> recommend just removing everything but "get" for now, since the  
>>>> feature
>>>> freeze means it is too late to redesign this.
>>
>> Once again I would omit this and treat like "get". I think being  
>> able to
>> specify the message body is a handy feature for "mailto:" submission.
>> But this is already offered via the "get" method, see
>> http://ftp.ics.uci.edu/pub/ietf/uri/rfc2368.txt and search for  
>> "body".
>> So "post" is not adding any new capabilities and therefore I think  
>> the
>> spec should omit this extension and treat it as an unknown method,  
>> i.e.
>> same as "get".
>
> Actually, the current descriptions of POST and GET match what UAs  
> do, in
> my limited testing. (I've changed PUT and DELETE to say they should  
> match
> GET instead of POST, though.) The upload part is new, of course.

I stand corrected. This seems fine.

>>>> I do not think it is right for the spec to call for undefined
>>>> behavior. The right way to leave behavior undefined is to not
>>>> specify it.
>>>
>>> I think it's much better to explicitly state when behaviour is
>>> undefined rather than leave the reader in the dark, but that's  
>>> another
>>> story.
>>
>> Well, submission behavior is also unspecified for "gopher:", "sip:",
>> "nfs:", and so forth. I do not think it is the spec's job to list  
>> every
>> URI scheme.
>
> No, but it's the spec's job to answer questions from implementors  
> as to
> exactly what they are supposed to do when the user submits a form to a
> protocol they support. The protocols listed were those most likely  
> to be
> encountered.

Agreed, but this is difficult when the URI scheme is not properly  
defined yet.


>> By my cursory testing, current UA behavior is to do nothing,  
>> effectively
>> disallowing javascript: as a submit action.
>
> My testing suggested that what happened was what I described under  
> "GET".
> I've removed the POST method, and defaulted post/put/delete to get.  
> It's a
> pity, the mechanism I described for POST was quite cool.

I stand corrected, my test case has a typo. Indeed the behavior is as  
you state. I'm glad I specified "cursory testing". :-)

>> Sure, but if there is no actual PUT operation, then it seems like the
>> right treatment is as unknown action. Why should POST be handled
>> differently for mailto: than, say, HEAD? Or FOOBAR? All three are
>> equally meaningless in this context.
>
> Well, in the mailto: case, POST and GET have always been treated
> differently. I understand what you mean, though.
>
> Let me know if the updated spec still has issues. I didn't change  
> all the
> things you raised, as noted above; let me know if you disagree with my
> reasoning above and think I should change the spec more.
>
>    http://whatwg.org/specs/web-forms/current-work/#methodAndEnctypes

I like most of the changes. I will review the revised file upload  
behavior and comment on that. I would also like to review the "data:"  
behavior in more detail to see if it seems appropriate. Other than  
that, I feel my concerns have been addressed, and I'll get back to  
you on the two points above.

Regards,
Maciej