Re: deprecating Postel's principle - considered harmful

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 10, 2019 at 04:47:34PM -0400, Phillip Hallam-Baker wrote:
> On Thu, May 9, 2019 at 10:00 PM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>
> wrote:
> > p.s.  I've often said that "the web" was optimized for deployability.
> > [...]
> >
> 
> Damn right it was. Deployability was the primary consideration. We did not
> use SGML because any of us liked it or considered it to be a solid
> technical specification. We hated it and we though it was crap. The reason
> we went there was that we needed buy-in from the publishing world.
> 
> But equally importantly, we broke a lot of what people thought were the
> rules. I knew that there wasn't a Content-Length header in MIME when I
> added it to the HTTP spec and so did Tim. But we pretended it did because
> we needed to make the POST method work and we were not going to introduce
> mandatory content body framing or SMTP type escaping.

Thankfully you did add chunked transfer-encoding.

> A lot of the reason that the Web is the way it was is that the exponent
> kicked in the growth curve while we were still trying to work out the
> architecture. And the Web grew much much faster than the bandwidth needed
> to serve it. Back in 1994, caching proxy servers were essential
> infrastructure needed to make the Web work. That isn't the case now. In
> fact TLS-everywhere is rapidly making them obsolete.

Is that so?  Caching proxies merely need to become MITM proxies.  Those
exist, and in many corporate environments that require web access and
data loss protection (DLP), they must exist.  I know because I use one,
and also I maintain one (though the one I maintain is not a caching
proxy).  Middleboxen will be with us forever.

Now, an MITM proxy that exists to enforce policy and implement DLP
needn't be a _caching_ proxy, so perhaps your statement is correct after
all!   :^)

But seriously, I don't expect proxies to go away.  I expect them to be
MITM proxies.

I'd rather that, instead of MITM proxies, clients used HTTPS to speak to
the proxy and did not use CONNECT for HTTPS resources, but that's not
likely to happen (and even so, if the user-agent must use client
certificates, it will have to use CONNECT), so MITM proxies they shall
have to be.

Nico
-- 




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux