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

>> 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

What I'm saying is that most servers do not implement the full HTTP
protocol, and we are now using this fact as a reason for not requiring
them to do so. If the protocol is broken let's fix it. If the servers
are broken, let's fix them.

>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.

The impact is much the same, except that remove the special case
"Simple Request" actually makes the protocol simpler, and more
orthagonal. Once again, I do not think that complicating the protocol 
because servers don't implement it properly is a good idea. Protocols
can, to a large extent, do without semantics. It's baggage that leads
to incompatible implementations.

>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.

In actual fact, the algorithm should also take the headers into
account as well. Indeed, it might be better to always hit the cache,
looking for the resource, before going off and fetching it. In such a
system, the caching would be controlled entirely by the server that
sent out the data (via headers).

Received on Wednesday, 7 February 1996 23:16:23 UTC