[whatwg] [WF2] form submission protocols and methods

[Maciej Stachowiak]

I think a lot of section 5.6 should be removed from the spec. In  
general the reasons are as follows:

- functionality that isn't really needed or is redundant with  
existing features
- features that are clearly insecure in web documents and may be a  
risk even in local files in a browser (therefore outside the scope of  
the spec)
- specifications of behavior for URI schemes that are not formally  
specified anywhere and are not broadly supported by UAs

To be more specific:

"File Submission" mode - this only seems useful with put/delete,  
however, the way this mode is triggered seems poorly thought out. It  
seems risky for the submission format to change entirely based on  
what set of controls you have in the form. Also, you might want more  
controls in the form that aren't themselves submitted but specify  
options for how to do the upload. Therefore I don't think this  
feature is useful as specified. It would be better if file upload  
semantics could be selected explicitly.

http: - "put" and "delete" are little-used methods on the web. To the  
extent they are used, it is as part of things like WebDav, where  
directly using them as part of a form submission is of dubious value.

ftp: - I do not believe any methods but "get" should have specified  
behavior. The spec itself says "ftp:" is not recommended as a  
submission method, so why extend it?

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.

file: - "post", "put" and "delete" are severe security risks even in  
documents that themselves come from file: URLs, since this would make  
downloaded HTML documents considerably more dangerous. The spec says  
"For security reasons, untrusted content should never be allowed to  
submit or fetch files specified by file URIs" but it is unclear what  
these means. If this is meant to apply to normal "file:" URL  
documents, then I strongly oppose these extensions. If it is not,  
then it is specifying behavior for some kind of special "trusted"  
mode which is not itself defined by this or any other spec, which  
seems outside the scope of the spec.

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.

smsto: / sms: - It seems overly aggressive to specify form submission  
behavior for URI schemes that are not themselves formally specified  
in any way. Indeed, the spec itself says "Behavior is undefined,  
pending the release of an smsto: or sms: specification." 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.

javascript: - This is redundant with onsubmit event handlers.  
Recommend removal. "javascript:" URLs are often sources of security  
risk since they make script to be executed look like a resource to be  
loaded, so it's better not to propagate their use further. The "post"  
semantics in particular seem silly, since script already has access  
to the states of the form controls and everything else in the  
document - why invent a new way to access that?

As a general comment, making "put" and "delete" have the behavior of  
"post", when they have no obvious semantic of their own,  seems  
questionable. They should be treated however unknown methods would  
be, since for those protocols they effectively are unknown.

I will send further comments on other sections as I review them.  
Mostly I expect to recommend removals to tighten up the spec.

Regards,
Maciej