Re: don't use POST for big GET [was: Dictionaries in HTML ]

    >(B) Except for issue #6, I see no problem with moving towards
    >the use of POST for queries, especially those that are too large
    >for encoding in GET URLs, or those with non-URL character sets.
    
    I still do not feel comfortable with this. Servers do not currently
    implement the full HTTP protocol, which allows GET to have bodies, and
    we use this as an excuse for not requiring them to do do.

I'm not sure what you are saying here.  I'm not arguing for
any change in the HTTP protocol's existing POST method.  It
already exists.  A server that doesn't implement POST can
avoid seeing them simply by not handing out HTML files with
	<FORM METHOD="POST">
right?

    On the other
    hand, you are proposing a new method, that would require many/most
    servers to be changed. It seems to me that it would be easier, and
    cleaner, in terms of implementation, to simply allow GET to have a
    body (ie. parameterised GET).

I think any change in the semantics of GET is equivalent (in its
impact on compatibility) to introducing a new method name.  Perhaps
worse, since if we use a new method, presumably an attempt to use
it through an HTTP/1.0 proxy will result in an error, whereas the
use of a GET with a body apparently causes some servers (and so
probably some proxies) to silently ignore the body.
    
    Caching can be controlled via headers,
    and by extending your algorithm like this:

        if method == GET {
            if URL does not contain "?" then
                go up the cache hierarchy
	    if there is no body then
                go up the cache hierarchy
       }
       bypass the cache hierarchy

This is not entirely satisfactory, because it means that if
there are GET+? (or POST) results that *are* cachable, then the
hierarchical caches will miss out on the opportunity for caching them.

For example, take the "ticker symbol lookup" form at
	http://www.secapl.com/secapl/quoteserver/search.html
Presumably, the mapping between stock ticker symbols and corporate
names does not change that rapidly, so it would be reasonable
to cache the results of these queries (with, say, a 1-day expiration
limit).

-Jeff

Received on Tuesday, 6 February 1996 17:47:30 UTC