Re: Round 2: moving HTTP 1.0 to informational

[www-html added, please delete http-wg from replies since this is more 
of an HTML directed post]

On Mon, 8 Jan 1996, Larry Masinter wrote:

> 	
> > The URI in a POST request identifies the resource that will handle
> > the enclosed entity as an appendage.
> 
> I know this language has been there forever, but 'as an appendage'
> doesn't really correspond to what people do with POST.
> 
> The data sent with a POST usually corresponds to information that
> results from an HTML form. I actually can't think of any other
> application.  Are there in fact any applications that POST anything
> other than form data? 

Sure. It is useful to shopping basket apps for passing session info 
transparently. Its non-cachability of results helps keep the baskets 
coherent in the face of extraordinarily dumb caches that fail to honor 
any other instructions not to cache things, and it also keeps people 
from making hotlists that include the session cookie as part of 
the URL. I would kill for the ability to use POST while making it
look like an A HREF link in most graphical browsers, without having to 
use an image.

A thought occurs to me - the artificial distinction between 
'A HREF' and 'FORM' is at the core of more than one problem with HTML 
(like URLs that choke SGML validators with imbedded '&' chars because
the defined standard for passing parameters seperates them with '&' 
chars). 

Why not re-visit 'A' containers and relieve the URL overloading 
by adding 'INPUT' type elements as allowed content and adding the 
'METHOD' attribute to 'A' (not to be confused with 'METHODS', although 
dangerously close in spelling)? 

Or alternatively, define a new TYPE="INLINESUBMIT" attribute value for 
'INPUT' in forms that is explicitly defined to display as 'inline 
text', (what a bizzare concept ;-) ) rather than the 'big buttons' pretty 
much every graphical browser now use. Thinking about it, this seems the 
superior approach. It takes fewer changes to the DTD and allows 
greater long term flexibility by leveraging off of forms.

> I'd suggest:
> 
> # The URI in a POST request identifies the resource that will handle
> # the enclosed entity as data to be processed, e.g., values from a
> # form that has been filled out.

Makes sense. It is certainly clearer.

-- 
Benjamin Franz

Received on Tuesday, 9 January 1996 10:59:55 UTC