Re: Introduction

Hi Poul-Henning,

Welcome; good to see you here.

On 11/03/2011, at 8:03 AM, Poul-Henning Kamp wrote:
> 
> 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.

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. 


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

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. 


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

Great.


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

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.


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

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.


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

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


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

+1


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

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

Cheers,

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

Received on Friday, 11 March 2011 20:35:51 UTC