[Nitro] Q about mongrel && nitro

Fang Sun nusgnaf at gmail.com
Sat Aug 5 06:37:48 EDT 2006


It should be mongrel do the trick, just quote mongrel rdoc:
"One additional caveat is that you don't have to specify the
Content-length header as the HttpResponse will write this for you
based on the out length."

On 8/5/06, Alexander Lazic <al-nitrogen at none.at> wrote:
> On Sam 05.08.2006 01:55, Fang Sun wrote:
>
> >Digging mongrel rdoc I found these interesting remarks on
> >Mongrel::HttpResponse implementation:
> >
> >"You may also work the HttpResponse object directly using the various
> >attributes available for the raw socket, body, header, and status
> >codes. If you do this you're on your own. A design decision was made to
> >force the client to not pipeline requests. HTTP/1.1 pipelining really
> >kills the performance due to how it has to be handled and how unclear
> >the standard is. To fix this the HttpResponse gives a "Connection:
> >close" header which forces the client to close right away. The bonus
> >for this is that it gives a pretty nice speed boost to most clients
> >since they can close their connection immediately."
> >
> >So, it seems that mongrel close the client connection mainly for
> >performance reason.
>
> Thanks for the point but, HTTP/1.1 pipelining is a little bit different
> then Keep-Alive requests.
>
> In RFC2616 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8)
> stands:
>
> ---
> 8.1.2 Overall Operation
>
> A significant difference between HTTP/1.1 and earlier versions of HTTP
> is that persistent connections are the default behavior of any HTTP
> connection. That is, unless otherwise indicated, the client SHOULD
> assume that the server will maintain a persistent connection, even after
> error responses from the server.
> .
> .
>
> ---
>
> and also
>
> ---
> 8.1.2.1 Negotiation
>
> An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to maintain
> a persistent connection unless a Connection header including the
> connection-token "close" was sent in the request.
> .
> .
> .
> 8.1.2.2 Pipelining
>
> A client that supports persistent connections MAY "pipeline" its
> requests (i.e., send multiple requests without waiting for each
> response). A server MUST send its responses to those requests in the
> same order that the requests were received.
>
> Clients which assume persistent connections and pipeline immediately
> after connection establishment SHOULD be prepared to retry their
> connection if the first pipelined attempt fails. If a client does such a
> retry, it MUST NOT pipeline before it knows the connection is
> persistent. Clients MUST also be prepared to resend their requests if
> the server closes the connection before sending all of the corresponding
> responses.
> .
> .
> .
> ---
>
> At the moment i don't know a client which use pipelineing, but this
> wasn't my issue ;-)
>
> What i have meant was that after the Set-Cookie-Header a futher header
> is send which is wrong!
>
> Anybody, nitro || mongrel, sends:
>
> ---
> "Date: Fri, 04 Aug 2006 23:00:29 GMT\r\nStatus: 200 OK\r\nContent-Type: \
> text/html\r\nSet-Cookie: nsid=376b3e39265fc699c62ab4aa3868e3e4; \
> Path=/\r\n\r\nContent-Length: 110\r\n\r\n"
> ---
>
> The '\r\n' is the 'delimiter' for the header as RFC2616 say ;-)
>
> My Question was now *who* send the Cookie-Header and *who* the
> Content-Length-Header?
>
> Sorry  for my unspecific question.
>
> regards
>
> Alex
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>


More information about the Nitro-general mailing list