[whatwg] [WF2] form submission protocols and methods

[Ian Hickson]

On Fri, 9 Dec 2005, Maciej Stachowiak wrote:
> > 
> > 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.
> 
> Sure, but I think in many cases the spec could just specify current de 
> facto behavior, instead of inventing new semantics.

I'm not intrinsically against that; at the time the new semantics seemed 
like good ideas. :-)


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


> [file upload behaviour]
> 
> I like the proposal of using a new enctype value, that makes it totally 
> clear when this behavior applies.

It's not really clear what the enctype would be, though... Conceptually, 
there isn't one (it's just whatever the file type is). Hmm.

For now I've left it as is (but see below).


> Under the current scheme upload format varies based on whether the user 
> has selected anything in the file upload control. This seems poor. 
> Submission should either fail in this case, or there should be some 
> defined behavior.

The current behaviour doesn't depend on whether there is a file selected 
any more; I fixed that after your last mail.

Basically currently the upload format will only be used if, if the form 
was submitted using any other format, there could not be anything 
submitted, regardless of what the user set the form controls to.

Let me know if you still think it should be changed, even with the new 
definition.


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


> > > ftp: - I do not believe any methods but "get" should have specified 
> > > behavior.
> > 
> > What should happen if the author specifies something else then?
> 
> As suggested below, treat as unknown method, i.e. like "get".

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.


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


> > > 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?)
> 
> "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.


> > 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."
> 
> If it's just a suggestion, it should go in a non-normative part of the 
> document.

Done.


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


> > > javascript: - This is redundant with onsubmit event handlers. 
> > > Recommend removal.
> > 
> > So what should happen when you submit to a javascript: URI?
> 
> 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.


> > > 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?
> 
> I said in the very next sentence what I would have them do!

Sorry. :-)


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

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