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:

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

...I am currently returning 505 to 1.0 clients. The reasoning is that the applications this server is intended to host will be highly dynamic "web 2.0+" (tho I truly hate that pseudo-term), and I am stuggling to find a business use case that really justifies legacy 1.0 support. I'd like to move away from the constraints of the 20th century but NginX could be the showstopper.

> Without knowing a lot
> about your particular
> application, I'm still inclined to venture that
> you are likely seriously
> over-concerned about the direness of this
> situation.

This is quite possible, but I cannot test fully as yet.

>
> With a notable exception, most of the additional
> benefits of HTTP/1.1
> you list (copied/pasted directly from the W3C
> page, I see)
> have little
> positive effect on performance between a proxy and
> a backend server that
> exist on the same LAN or especially the same
> machine. They are mostly
> of benefit between a server and a user-agent
> (browser) or over
> slower-than-LAN links. Perhaps you should
> provide your own, actual
> reasons (or better yet, test results) that
> demonstrate this is more than
> an imagined fear. I'm fully prepared to believe
> that your app might
> require HTTP/1.1, but copying reasons from the W3C
> site isn't entirely
> convincing.

true ...<knuckle rap>, 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.

>
> No doubt there are many applications that would
> benefit from things like
> chunked responses (I believe range requests should
> pass through
> successfully, but haven't tested),

I have my hands 110% full, but will likely be able to do that kind of testing later.However, note that this means I'm being asked to test other technologies rather than just my own, so frankly it's not going to be on my no.1 priority list and I may just have to go with a different front end recommendation at release.

> but unless you
> are saying that you
> have that sort of application, then I'd suggest
> you simply test and see
> if it works. I've heard rumor that premature
> optimization is the root
> of a significant amount of fail ;-)

..that is *without doubt* true. However, usually that is related to sequential code. There are design/structural limitations that should be addressed early, and support for HTTP/1.0 does have structural impact on the codebase.

>
> > The 1.0 constraint is pretty dire for me. Do I
> have alternatives to
> > proxy-pass/upstream that would allow me to use
> Nginx or should I be
> > looking at another HTTP server?
>
> If you really believe you need HTTP/1.1 between
> Nginx and the backend
> (note that Nginx *does* support 1.1 to the
> browser), then you'll need to
> look elsewhere. I believe that 1.1 support
> between Nginx and backend is
> in the works, but sadly it doesn't exist today.
>
> Sorry that I can't give you something more
> positive. But I do
> encourage you to not give up unless actual testing
> (or some known
> condition you haven't mentioned) demonstrates that
> HTTP/1.0 is a
> demonstrable failure for your application.

NP at all. A correct answer is worth 1000 answers that pander to some ideal or fantasy.
>
> Regards,
> Cliff
>

My best regards to you also!

Steve