[Nitro] Q about mongrel && nitro

Alexander Lazic al-nitrogen at none.at
Sat Aug 5 03:18:49 EDT 2006


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


More information about the Nitro-general mailing list