Re: request for new forms submission consensus

Tony Sanders <sanders@bsdi.com>
Errors-To: sanders@bsdi.com
Message-id: <9310161945.AA24430@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: request for new forms submission consensus 
In-Reply-To: Your message of Sat, 16 Oct 93 12:06:37 PDT.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Sat, 16 Oct 1993 14:45:20 -0500
From: Tony Sanders <sanders@bsdi.com>

> Tony Sanders responds:
> | I would just say that forms always get POST'ed, why would you ever need
> | some other method?

Chris McRae writes:
> Perhaps a more pertinent example is available in constructing an HTML WAIS
> interface.  After receiving search results including interesting documents
> and some additional WAIS sources, the user will want to refine the search
> by selecting the interesting items and re-searching:
> <FORM ACTION="TEXTSEARCH wais://cnidr.org:210/$search_spec?blah">
I understand what you want to do, I just disagree with putting this
into HTML and the client.

    FYI: TEXTSEARCH isn't a valid method it's just an attribute of an
    object (e.g., Accept: TEXTSEARCH).  Same goes for SPACEJUMP.  The
    query is still done with a GET like always.

All of this can be done in the protocol within the confines of POST
*and* be much more flexible.  For example, redoing your example:

document:
    Select A stored query:
    <FORM ACTION="http://server1/select"> <SELECT NAME=query> ...

request:
    POST /select HTTP/1.0
    ...
    query=BLAH-directory-of-servers.src?foobarbatbaz

response:
    HTTP/1.0 302 Found
    Location: wais://waisserver/BLAH-directory-of-servers.src?foobarbatbaz
    ...

Ta-da.  And now I can redirect all the queries on the fly (gee, think.com
is down, lets try xyz.edu) *without* having change ANY of the documents.
You need to use a different method than POST?  No problem, just reply
like this:

    HTTP/1.0 303 Method
    Method: ADMIN http://blah.com/BLAH-directory-of-servers.src
    ...

See, no need to change the protocol, or add crap to HTML or add a limitless
amount of code to EVERY client.   Hacking stuff like this into client is
an intractable solution to the problem, there are too many variables and
things are changing too fast.  The server side solution that HTTP implements
let's you scale the solution with the problem.

--sanders