Re: Method for A? (fwd)

Mike Meyer (mwm@contessa.phone.net)
Thu, 25 Sep 1997 12:44:35 PST


In-Reply-To: <199709251751.KAA00356@server.livingston.com>
From: mwm@contessa.phone.net (Mike Meyer)
To: www-html@w3.org
Date: Thu, 25 Sep 1997 12:44:35 PST
Message-ID: <19970925.770F1A8.BA21@contessa.phone.net>
Subject: Re: Method for A? (fwd)

> Date: Thu, 25 Sep 1997 10:51:40 -0700 (PDT)
> From: MegaZone <megazone@livingston.com>

> I have never seen any need for POST on A.  POST is only needed when
> sending volumes of data to a server, which only results from FORM
> submissions.  I have never in 5 years of working on the web seen any
> need for POST associated with A.

POST was *originally* for sending large chunks of data. HTTP/1.1
changed that, by stating in Section 9.1.1:

 In particular, the convention has been established that the GET and
 HEAD methods should never have the significance of taking an action
 other than retrieval. These methods should 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.

In practice, this means that browsers authors seem to feel that they
can do GETs whenever they want (on a window resize, for instance), but
need to check with the user before doing a POST.

> Please provide a concrete example.  I see nothing in the current
> specification that would require METHOD on A.  And if you did it on A
> remember there are other links - such as image maps.

Server-side image maps are wrapped in an A tag. Client-side image maps
may need this.  I specifically mentioned that other things may need
this at the end of the proposal.

Here's a concrete example of an abstract(ed) application.

I've got a gateway to a statefull database. At any give time, the
database has a list (possibly) of "active" objects, and a current
object. One of the web interfaces displays the current object, and a
list of actions that can be taken on that object. The list of actions
is simple, and is currently coded like:

	<A HREF="gateway.cgi?ACTION=NEXT">Next</A>,
	<A HREF="gateway.cgi?ACTION=CURRENT">Current</A>,
	<A HREF="gateway.cgi?ACTION=PREVIOUS">Prev</A>,
	<A HREF="gateway.cgi?ACTION=SAVE">Save</A>,
	<A HREF="gateway.cgi?ACTION=PROCESS">Process</A>,
	<A HREF="gateway.cgi?ACTION=DELETE">Delete</A>.

This could also be (in fact, at one time was) coded as:

	<FORM ACTION="gateway.cgi" METHOD=POST>
	<INPUT TYPE=SUBMIT NAME=ACTION VALUE=NEXT>
	<INPUT TYPE=SUBMIT NAME=ACTION VALUE=CURRENT>
	<INPUT TYPE=SUBMIT NAME=ACTION VALUE=PREVIOUS>
	<INPUT TYPE=SUBMIT NAME=ACTION VALUE=SAVE>
	<INPUT TYPE=SUBMIT NAME=ACTION VALUE=PROCESS>
	<INPUT TYPE=SUBMIT NAME=ACTION VALUE=DELETE>
	</FORM>

The rendering in graphical browsers for this pretty much sucks, and it
really isn't fixable.  Changing the displayed text requires changing
the gateway. In Lynx, you can follow the A version with numbers, but
that doesn't work in the FORM version.  If you need a second value
attached to each submit (i.e. "?ACTION=WHATEVER&OBJECT=FOOBAR") that
has the same name but different values requires more forms, which
screws up the presentation even further.

Basically, the <A> version is better in all ways but one. That one is
that popular browsers feel free to reload the displayed page without
checking with the user.

In particular, resizing the display after deleting an object caused at
least one major browser to reload the page, resulting in the NEXT
object also being deleted "accidently". This actually happened once.

The goal is that pages fetched with a POST can not be safely refetched
without asking the user would have prevented this from happening.

> IMHO moot point - I don't think any major vendor would bother with it.

In that case, why do we bother with a standards organization at all?

	<mike