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
