- From: Koen Holtman <Koen.Holtman@cern.ch>
- Date: Thu, 11 Mar 1999 10:19:43 +0100 (MET)
- To: Yaron Goland <yarong@microsoft.com>
- cc: "'Keith Moore'" <moore@cs.utk.edu>, web@apps.ietf.org, discuss@apps.ietf.org
On Wed, 10 Mar 1999, Yaron Goland wrote:
[Yaron:]
> > > P.S. As for HTTP's complexity. HTTP itself is an unbelievably simple
> > > protocol. The problem is that it has inherited a lot of
> > cruft over the
> > > years, 99.99% of which is optional and not widely
> > supported. I believe that
> > > what the world really needs is a re-written version of the
> > HTTP spec. One
> > > organized into a more rational structure which shows the
> > true beauty of
> > > HTTP's layered architecture. I would be willing to bet that
> > one could write
> > > a spec providing the absolute bare minimum information
> > needed to create a
> > > compliant client/proxy/server in 20 pages.
> >
[Kieth:]
> > That seems like a stretch - in particular the interaction of cacheing
> > proxies is just too complex. But I'd love to see somebody try.
> >
>
> Caching proxies are simple, **IF** you only do the basic caching that actual
> works. People run into problems when they try to get fancy and support
> features no one needs or uses. I would bet you could explain the entire
> minimally compliant/maximally useful HTTP proxy caching system in two pages.
Yes, I agree here, a compliant/useful HTTP proxy cache specification does
not have to be very long. More exotic things like Vary and the merging of
range responses can be left out. Even a lot of the cache-control
directives can be left out, by speficying that they should all be treated
as 'don't cache'.
It is true that caching proxies can interact in very complex ways, this is
unfortunate but it was unavoidable in HTTP/1.1. We already had an
installed base we needed to be compatible with, and this installed base
included design decisions that were subtly wrong in retrospect.
But proxy implementers can blisfully ignore most of the proxy interaction
complexity, if the goal is just complicance. HTTP/1.1 puts the problem
of dealing with the complexity on the plate of dynamic web content
designers and (especially) protocol extension designers.
One of the projects way down on my 'todo' list is to take HTTP/1.1, drop
lots of stuff, straighten out the layering, and write the result up in a
small document called 'http light'.
Koen.
Received on Thursday, 11 March 1999 04:21:12 UTC