[whatwg] [WF2] form submission protocols and methods

On Fri, 9 Dec 2005, Maciej Stachowiak wrote:
> 
> I think a lot of section 5.6 should be removed from the spec.

Most of section 5.6 consists of defining behaviour to ensure 
interoperability between implementations, since if the spec doesn't list 
what happens then implementations either have to reverse-engineer each 
other or end up not doing the same thing.

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.


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

The set of conditions that are required to make the "File Upload" mode 
kick in are exactly the conditions that would otherwise make the 
submission useless (namely, enctype is not a type that supports file 
upload, and there is no other data to submit).

The alternative is to submit the filename or nothing, which doesn't seem 
useful at all.

By having the "File Upload" mode we can easily provide a way for HTML to 
support HTTP PUT, file: saving, FTP upload, etc. Currently there is 
basically no way to do these things from HTML.


> It seems risky for the submission format to change entirely based on 
> what set of controls you have in the form.

Hmm, true, it's a bit ambiguous the way it is currently defined. Ok, I've 
changed the definition a bit to be less risky.


> Also, you might want more controls in the form that aren't themselves 
> submitted but specify options for how to do the upload.

The new definition allows that. Let me know if that is better:

   http://whatwg.org/specs/web-forms/current-work/#missing-enctype


> It would be better if file upload semantics could be selected 
> explicitly.

True. Maybe a new enctype value instead?


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


> ftp: - I do not believe any methods but "get" should have specified 
> behavior.

What should happen if the author specifies something else then?


> The spec itself says "ftp:" is not recommended as a submission method, 
> so why extend it?

It's not a matter of extending it, it's a matter of defining it so that 
all UAs can converge on the same behaviour.


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


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

What is unclear? The term "untrusted content" or the phase "allowed to 
submit or fetch"? (Or something else?)


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

As the spec says: "The semantics described in this subsection are 
recommended, but UAs may implement alternative semantics if desired, as 
consistent behaviour for submission to file: URIs is not required for 
interoperability on the World Wide Web."


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

Assuming there is no feature freeze, how would you do it? I assume that 
when I specified this I tried to make it match implemented behaviour while 
defining the parts that weren't interoperably implemented. In particular, 
note that with mailto: URIs, the enctype is usually set to text/plain 
which is a lot more readable than most submission types.


> 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've commented these out for now.


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


> javascript: - This is redundant with onsubmit event handlers. Recommend 
> removal.

So what should happen when you submit to a javascript: URI?


> As a general comment, making "put" and "delete" have the behavior of 
> "post", when they have no obvious semantic of their own, seems 
> questionable.

What would you have them do instead?


> They should be treated however unknown methods would be, since for those 
> protocols they effectively are unknown.

If it's not known, it's treated as GET. We could do that instead, it just 
seemed that PUT's semantics were closer to POST than GET.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 9 December 2005 15:42:49 UTC