[Nitro] Q about mongrel && nitro

Alexander Lazic al-nitrogen at none.at
Sun Aug 6 05:27:22 EDT 2006

On Son 06.08.2006 01:03, Zed Shaw wrote:
>On Sat, 2006-08-05 at 19:56 +0200, Alexander Lazic wrote:
>> Thanks to open it a little bit ;-)
>> What do you think to add a *switch* so that we can use some
>> proxy-modules which are use the keep-alive without the pipline ;-)
>> What i think about is such behaviour:
>> Default => Connection: close
>> with --keep-alive be RFC conform ;-)
>> Thoughts?!
>No.  If your proxy doesn't close the connection when it encounters
>"Connection: close" then ***it's*** not following the standard.

Full ack, the most proxies close the connection ;-)

>That's why Mongrel does it. So that it can process one request at a
>time but still follow the standard. Simply not sending this header does
>not magically make Mongrel descend into the nasty ugly part of the RFC
>around "keep-alive" and "pipe-lining".

Also ack.

>Finally, while you may think "keep alive" and "pipe line" are
>different, they aren't. It's kind of like saying a salmon is different
>from a fish.  You need one to have the other, so there's no point
>arguing some imaginary difference between the two.

Ack but the revese statement, keep-alive without pipeline can't work,
isn't valid, from my point of view.

There are many clients and server which use keep-alive without
pipelineing as i know.

To make a simple statement:

You can use keep-alive without piplineing.
You can't use piplineing without keep-alive.

Can you agree with that?!

A bigger *uglier* i find is the Transfer-Encoding: chunked ;-)

>Anyway, not gonna happen any time soon, and it's not really needed.
>It's a *huge* (let me repeat, gigantic, massive *all fake*) myth that
>turning keep-alives on and pipe-lining requests over HTTP makes your
>app faster.  It's a load of bull that had dubious motivations (think MS
>vs.  Netscape) back in the day when clients were pathetic (things
>changed thanks to DDoS) and was backed by sad little statistics.

May be for plain HTTP but for HTTPS it's a *really big* performance
issue, i have seen this in may all day work ;-)

>Sorry, but people who fret over keep-alive and pipe-lining I've found
>either use broken proxies or don't want to design their services around
>batched processing.

I think that keep-alive could be a help for server and client if all
components between works correct ;-)

I don't see 'keep-alive and pipe-lining' as i wrote before i see:

keep-alive or (keep-alive and pipe-lining)


BTW: which #irc-server && channel have you mean ;-)



More information about the Nitro-general mailing list