Re: pls change main validator form back to GET

Dan Connolly <connolly@w3.org> wrote:

>On Mon, 2002-12-02 at 20:45, Terje Bless wrote: [...]
>>>Strictly speaking these are two interpretations of the HTTP methods,
>>Not necessarily. Iff a "TAG Finding" carries force of fiat [...]
>
>Consider the tag finding irrelevant.

Ok. But out of curiosity, what exactly is the authority of a TAG Finding?
Are they purely informational until such time as they get incorporated into
a WebArch REC? Or is this something best left alone right now? :-)


>It's [the HTML and HTTP] specs that provide the motivation for my
>request; once again:
>
>[[[
> The "get" method should be used when the form .... causes no
> side-effects.
>]]] -- <http://www.w3.org/TR/1999/
>REC-html401-19991224/interact/forms.html#h-17.13.1>

Well, as Jim mentioned, whether the form on v.w3.org has "side-effects" is,
at the very least, debatable. As is, IMO, the definition of "side-effects"
in the general case. Once man's side-effect is another man's idempotency.

In particular, the "check" CGI script is certainly idempotent, but it does
have side-effects over and above what is usually expected of a GET (on,
e.g., a static HTML file or a .shtml etc.).


Apart from the two possible interpretations of the specs, this is also a
case of a tradeoff between strict technical correctness and usability. As
Jim brings up, the reason for the consolidated form is to improve
usability. Multiple submit buttons for what, from a user perspective, is a
single form -- and which appear to, but do not in fact, do the same thing
-- is terrible human interface.

Consider the failure modes of the two models for minute!


>[[[ Implementors should be aware that the software represents the user
>in their interactions over the Internet, and should be careful to allow
>the user to be aware of any actions they might take which may have an
>unexpected significance to themselves or others.
>
>In particular, the convention has been established that the GET and HEAD
>methods SHOULD NOT have the significance of taking an action other than
>retrieval. These methods ought to be considered "safe". This allows user
>agents to represent other methods, such as POST, PUT and DELETE, in a
>special way, so that the user is made aware of the fact that a possibly
>unsafe action is being requested.
>
>Naturally, it is not possible to ensure that the server does not
>generate side-effects as a result of performing a GET request; in fact,
>some dynamic resources consider that a feature. The important
>distinction here is that the user did not request the side-effects, so
>therefore cannot be held accountable for them.
>]]]
>-- http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1

This is pure wishfull thinking on RFC 2616's part! No such convention has
or had been established; RFC 2616 is trying to establish it. It's
suggesting Best Current Practice, but failing to label it as such, much
like the TAG Finding you cited.

Further, the RFC is making claims about social and legal issues over which
it has no control, much less authority or mandate. You will never be able
to argue that, legally, a purchase, say, made with GET is less binding then
one made with POST.

In practice, the distinction RFC 2616 seeks to make is implemented at a
higher level then HTTP (the Presentation layer vs. the Application layer if
I remember my OSI correctly). No current User Agents distinguish between
GET and POST (in any meaningfull way), so it is up to the "web page"
surrounding the resulting transaction to indicate its consequences.

IMO, this is also where it belongs. I might buy a HTTP method which has
attached semantics such as suggested above (the postulated "REST" method,
say), but POST ain't it.

More appropriate IMO, would be to leave the transport protocol generic (or,
perhaps, "transparent" would be more accurate) and make the distinction at
a higher level such as the XForms specification. That would (still "IMO")
be the appropriate place to indicate what semantics are attached to the
transaction.

GET vs. POST should be an implementation choice and mostly based on such
things as "bookmarkability" and whether you need your request to have a
body (e.g. multipart/x-www-form-url-encoded vs. multipart/form-data).

Dragging in "idempotency" (no matter which way you choose to use the term)
and alledged legal distinctions of liability attached to an implementation
detail smacks far too much of hand-waving justification for a foregone
conclusion and wishfull thinking (and I use the terms/phrases in their
logical meaning, not as colloquial insults).



Thus my conclusion earlier and above; this issue is still up for debate and
it is inappropriate to make absolute claims about an alledged One True Way
to interpret and implement this.


Best Regards, Terje.




-- 
When I decide that the situation is unacceptable for me, I'll simply fork
the tree.   I do _not_ appreciate being enlisted into anyone's holy wars,
so unless you _really_ want to go _way_ up in my  personal shitlist don't
play politics in my vicinity.                   -- Alexander Viro on lkml

Received on Wednesday, 4 December 2002 00:49:18 UTC