Re: Method for A?

Mike Meyer (mwm@contessa.phone.net)
Thu, 25 Sep 1997 11:47:43 PST 

In-Reply-To: <v03110704b050516dbdce@[205.149.180.135]>
From: mwm@contessa.phone.net (Mike Meyer)
To: www-html@w3.org
Date: Thu, 25 Sep 1997 11:47:43 PST
Message-ID: <19970925.7701910.AE55@contessa.phone.net>
Subject: Re: Method for A?

> Date: Thu, 25 Sep 1997 10:42:50 -0700
> From: Walter Ian Kaye <walter@natural-innovations.com>

>  > The A tag has no such attribute, nor any other method to let the
>  > author select which of the two HTTP methods should be used.  When an
>  > author wishes the UA behavior or rendering of the A tag, but the
>  > application at the server has the semantics of the POST method, the
>  > author is stuck.
> I don't understand why you would need this. Why not just use a FORM?

Because the UA treatment of form buttons is undesirable in some cases.
There's also the idiotic linking of the button label to the name/value
pair it sends to the server.  This lets you avoid both of those
problems.

>  > User agents that predate this change should ignore the METHOD
>  > attribute and use the GET method. This may mean that the UA and the
>  > server don't agree on the semantics of the requested object.  While
>  > this is undesirable, it's also the only current option when when the A
>  > tags UA behavior/rendering is desired for a hyperlink source whose
>  > destination has POST semantics.
> What sort of destination would that be?

One that uses a dynamic process on the other end that isn't "safe" [*].

> And here's the killer question: Where do you put the post *data*? Do you
> create a new attribute for A to hold the data value? It is most definitely
> not part of the URL.

Part of the URL where? In the test implementation, the author writes
the same URL as they would for a GET request. This is required for
backwards compatibility. A UA that implements this features pulls the
query off the request, finds it's length, and sends it as the content
of a POST. It works fine in practice.

Yes, there are FORMS that can't properly be turned into a POST, and
there are issues of the length of a URL. Those can't be turned into a
GET, either. I'm not concerned about them. Are you?

	<mike

*) From HTTP 1/1, section 9.1.1.