In-Reply-To: <email@example.com> From: firstname.lastname@example.org (Mike Meyer) To: email@example.com 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 <firstname.lastname@example.org> > > 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.