Subject: Introduction

From: Poul-Henning Kamp <[email-masked]>
Date: Fri, 11 Mar 2011 16:03:23 +0000

Hi there,

I'm the author of the Varnish HTTP accelerator and have just joined
the mailing list, so I thought it would be proper if I introduced
myself.

About me:
---------

Until I got roped into writing Varnish, I was one of the primary
FreeBSD kernel developers, and Varnish was sort of a detour for me,
which has so far lasted five years.

As you can see in my .signature, I've been around for a while, I've
written an OSI-TP4 stack on a 3B2 computer and 21 years ago I
replaced OSI protocols with TCP/IP in the European Parliament,
happily configuring 1200-some PC's with IP numbers, only to find
out when RFC-1166 came out, that Sue Romano had mistyped our
IP allocation in the letter, so they all had the wrong address.

Apart from my work in FreeBSD, I'm probably most unknown as the
author of the "md5crypt" that protects the majority of all passwords
on the net and the http://bikeshed.org rant, bourne out of frustration
with herding cats in the FreeBSD project.

All this is just to say that I have paid my dues with respects
to standards and have the scars to prove it.

About HTTP and Varnish:
-----------------------

Before I started Varnish, HTTP was not something I had cared about
particularly, but since I had to write an implementation from
scratch, I read RFC2616 and what else I could lay my hands on.

And then I did a lot of data-analysis on actual website traffic to
see what was actually going on, and finally started writing the
code, which now has become the new black a lot of places.

I know I am going to rub some of you the wrong way when I say this,
but I decided early on that it would never be a goal of mine to
make Varnish totally RFC2616 compliant.

RFC2616 contains a lot of stuff that is never used, some of it is
even patently useless, but a lot of it is just not used in practice,
at least not in the application space where Varnish resides.  Those
bits will not be implemented in Varnish as long as they see no use
on the internet.

I have yet to see a Content-MD5 for instance.

But for all parts of HTTP which Varnish implements, I strive to be
compliant with with the standards.

HTTPng and me:
--------------

I have finally decided to join the HTTPng mailing-list, not
something I do lightly, I get email enough as it is, but as
more and more content gets delivered through Varnish, I need
to be a bit more proactive with what HTTP becomes.

The history of HTTP is far from ideal, and we suffer from old
mistakes, but I would really appreciate if we could avoid making
more of them.

Today, in my corner of the world, HTTP is a high-performance delivery
protocol, sites are looking for response times south of milliseconds
and it is quite limited how much text-processing you can do under
those circumstances and anything that costs time or bandwidth will
not gain widespread use.

And that brings me to what triggered me to get on board:

draft-thomson-hybi-http-timeout-00

I don't see any obvious harm from these two proposals, but I think
at least one of them could be done better.

A) Can somebody explain to me, why we need an entirely new header
   called "Connection-Timeout", when we could just add "timeout=%d"
   to the already existing Connection: header, thus avoiding about
   31 bytes of overhead and some needless text-processing ?

B) Why is that header bidirectional ?   What would a server use a
   Connection-Timeout: header from a client for ?

C) Is it enough to send the timeout in the first response on a
   HTTP connection, or does it need to be included in all responses
   on that connection ?

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 11 Mar 2011 11:59:37 -0800

> the mailing list, so I thought it would be proper if I introduced

Hi Poul-Henning, it's nice to have you here.

> I have yet to see a Content-MD5 for instance.

No problem.  I did the same thing with 2616 (Apache httpd
implemented 2068 and then I was way too busy trying to get
my dissertation done to pay attention to 2616, sadly).
HTTP has gone through several waves of expansion, as various
experiments were deployed, and then contraction as we figured
out which ones didn't work in practice.

> compliant with with the standards.

Great.  Is there any chance that you have a list of features
or requirements that you did not implement (on purpose)?

I don't have much opinion on the proposed timeout features,
but I do wish that folks would pick shorter names and make
use of the existing ones (like the options on keep-alive).

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 11 Mar 2011 12:35:20 -0800

Hi Poul-Henning,

Welcome; good to see you here.

> make Varnish totally RFC2616 compliant.

Most implementations aren't completely compliant, and even (if any?) fewer implement every feature. That's OK. Our goal here is to improve the quality of the documentation so that implementers like you have clearer instructions and better indications of what's appropriate to implement. 

> bits will not be implemented in Varnish as long as they see no use

Right. To be absolutely clear, you don't need to implement everything in HTTP to be compliant. One of my goals is to make this more obvious, and to make it clear which requirements apply to different classes of implementers. And, where it is clear that there isn't any use nor interop (e.g., 305 Use Proxy), we can deprecate features.

> I have yet to see a Content-MD5 for instance.

They're pretty rare, yes. 

> compliant with with the standards.

Great.

> HTTPng and me:

To be clear -- we're not ng (evolving the protocol), we're bis (revising the spec to make it better). However, there are lots of background discussions on what's next for HTTP -- both in terms of new headers / functionalities, and changing the protocol overall -- and they tend to get discussed here.

> at least one of them could be done better.

Agreed. Just FYI, that draft was targetted at the hybi list (which is working on WebSockets), but discussion is going to inevitably happen here too.

>   31 bytes of overhead and some needless text-processing ?

+1, or use Keep-Alive timeouts (as Roy mentions).

>   Connection-Timeout: header from a client for ?

+1

>   HTTP connection, or does it need to be included in all responses

Good question. I have other reservations that I'll post separately.

Cheers,

--
Mark Nottingham   http://www.mnot.net/  (HTTPbis WG Chair)

---

From: Adrian Chadd <[email-masked]>
Date: Sat, 12 Mar 2011 09:40:29 +0800

> the mailing list, so I thought it would be proper if I introduced

Welcome!

Adrian