[Nitro] Q about mongrel && nitro
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 ;-)
>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".
>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
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