Proxy pass, upstream and http/1.0

Maxim Dounin mdounin at mdounin.ru
Thu Jul 30 15:41:52 MSD 2009


Hello!

On Thu, Jul 30, 2009 at 06:10:49AM -0400, komone wrote:

> Hi Cliff,
> 
> It seems I put you on the defensive a little, or sounded aggressive, neither of which was my intention. 
> 
> Here's a little more detail (inline with your responses)...
> 
> Cliff Wells Wrote:
> > Many, if not most, people using Nginx are proxying
> > to application
> > servers (myself included).   
> 
> I am writing a web application server which is *intended* to run behind a proxy so that I can rely on delegating SSL/TLS, mail proxying, and (for the largest part, but not all), static file serving, rather than simply re-inventing the wheel.
> 
> HTTP/1.0 is largely a dead protocol, and the only cases I can find that require 1.0 in this server are:

Just a note: you can't be HTTP/1.1 complaint without correct 
support for HTTP/1.0.

On the other hand, HTTP/1.1 is much more complicated.

That's basically why nginx uses HTTP/1.0.

> Lynx, Wget, and... NginX (which was to be my favored proxy)

Just some arbitrary stats from some frontend server:

$ fgrep 'HTTP/1.0' access_log | wc -l
   62734
$ fgrep 'HTTP/1.1' access_log | wc -l
 1979061

So it's about 3% of HTTP/1.0 requests anyway.  This includes 
various proxies, mobile phones, various robots etc.  AFAIK IE 
still uses HTTP/1.0 by default if configured with proxy.

[...]

> true ..., however I'm concerned that more issues will raise their head further down the road and I don't want to paint myself into a corner... inability to do chunked transfers by itself seems to be good enough reason for concern to me.

Chunked transfer encoding has basically two goals:

1. keep connections alive
2. ensure data consistency in case of connection drop

Both apply only in case you have no known Content-Length.  
And benefits of both are highly questionable in case of 
frontend-backend connection.

If you have connection drops - you are in trouble and HTTP/1.1 
won't help anyway.

Keeping connections alive is mostly performance question, and 
doesn't really apply unless you have either very fast backend or 
something wierd that spends lots of resources on opening new 
connections.  And, actually, HTTP/1.1 support doesn't imply 
keepalive connections support.

I'm currently working on HTTP/1.1 support to make it possible to 
keep http connections alive.  But it doesn't looks for me that 
HTTP/1.0 is somewhat limiting.  Just performance issue for very 
special cases.

Maxim Dounin





More information about the nginx mailing list