Fastcgi, simply wrong

Hi folks,

i’ve just dedicated some hours upon the nginx behavior/source code
(version 0.6.29, but also happens to 0.5.35)
towards fastcgi protocol and discovered that the requestId is fixed,
it’s simple always equal do 1, this break the
the concurrency completely (as i’ve proved easily) and it also
causes early closed connections from the web
server/client became out-of-sync with the request state in correctly
implemented fastcgi applications, not
trying to be unpleasant, but i think that saying that nginx supports
fastcgi can do more harm than good to
the project… passing by just to say this, hope you guys find a
good solution, im out.

fastcgi is a good thing, see (and think) for yourself

“rationality and objectivity is greatly discredited in these days” –
George Soros

Alexandre Girao

Hello!

On Fri, Apr 25, 2008 at 01:11:26AM -0300, Alexandre Girao wrote:

Hi folks,

i’ve just dedicated some hours upon the nginx behavior/source code
(version 0.6.29, but also happens to 0.5.35)
towards fastcgi protocol and discovered that the requestId is fixed,
it’s simple always equal do 1, this break the

Since nginx doesn’t send more than one request within single
connection to FastCGI application - there is nothing wrong with
requestId always being 1.

See http://www.fastcgi.com/devkit/doc/fcgi-spec.html#S3.3 for
details. Quote:

% The Web server re-uses FastCGI request IDs; the application
% keeps track of the current state of each request ID on a given
% transport connection.

the concurrency completely (as i’ve proved easily) and it also
causes early closed connections from the web
server/client became out-of-sync with the request state in correctly
implemented fastcgi applications, not
trying to be unpleasant, but i think that saying that nginx supports
fastcgi can do more harm than good to

If you experience problems with this - it’s likely due to problems
with FastCGI protocol implementation in your application. The way
how nginx talks to application may be not fastest one, but it’s
perfectly correct as far as I see.

Maxim D.

Alexandre Girao ha scritto:

trying to be unpleasant, but i think that saying that nginx supports
fastcgi can do more harm than good to
the project… passing by just to say this, hope you guys find a
good solution, im out.

Note that, as far as I know, Apache and Lighttpd does not supports
multiplexing.

This is not only hard to implement, but it is also not well designed in
FastCGI.

There are some comments here:
http://twistedmatrix.com/trac/browser/trunk/twisted/web2/channel/fastcgi.py

fastcgi is a good thing, see (and think) for yourself

Well, not all people think that FastCGI is a good thing.

Manlio P.

On Fri, Apr 25, 2008 at 02:47:40PM +0400, Igor S. wrote:

FastCGI servers, those support multiplexed connections. Some of them,
such as Mongrel, can not handle two simlutaneous requests even over
different connections.

Oh sorry, Mongrel is HTTP server, but not FastCGI one.

On Fri, Apr 25, 2008 at 01:11:26AM -0300, Alexandre Girao wrote:

the project… passing by just to say this, hope you guys find a
good solution, im out.

fastcgi is a good thing, see (and think) for yourself

Although FastCGI was designed 12 years ago, it was not widespread until
several years ago, when lighttpd had appeared. So many FastCGI servers
has no full protocol support and I’m no sure that now there are
widespread
FastCGI servers, those support multiplexed connections. Some of them,
such as Mongrel, can not handle two simlutaneous requests even over
different connections.

So nginx has no full FastCGI support that reflects the current FastCGI
servers support.

On Fri, Apr 25, 2008 at 5:02 AM, Maxim D. [email protected]
wrote:

towards fastcgi protocol and discovered that the requestId is fixed,
it’s simple always equal do 1, this break the

Since nginx doesn’t send more than one request within single connection to
FastCGI application - there is nothing wrong with requestId always being 1.

i really understand what you say here, and it will work, but this is
“simply wrong”.

On Fri, Apr 25, 2008 at 5:02 AM, Maxim D. [email protected]
wrote:

towards fastcgi protocol and discovered that the requestId is fixed,
it’s simple always equal do 1, this break the

Since nginx doesn’t send more than one request within single connection to
FastCGI application - there is nothing wrong with requestId always being 1.

ok, but my application (which btw works perfectly with
lighttpd/apache) tracks request state based on the request id, just as
specification says, if i change my application to track request states
based on connection… geee… this is ugly

See http://www.fastcgi.com/devkit/doc/fcgi-spec.html#S3.3 for details.
Quote:

% The Web server re-uses FastCGI request IDs; the application
% keeps track of the current state of each request ID on a given
% transport connection.

the specification is not saying that the webserver can fix the request
id, it simple says that after a request id is over (full life cycle)
it can be reused, indeed, this just reinforces my previous paragraph…
that i need to track request state based on the request id

the spec says “the application keeps track of the current state of
each request ID” not “the application keeps track of the current state
of each transport connection”

On Fri, Apr 25, 2008 at 6:59 AM, Manlio P.
[email protected] wrote:

causes early closed connections from the web
multiplexing.

This is not only hard to implement, but it is also not well designed in
FastCGI.

There are some comments here:
http://twistedmatrix.com/trac/browser/trunk/twisted/web2/channel/fastcgi.py

i wont argue on the competency of the code and comments of that guy,
im interested in technical superiority and i found it in fastcgi
protocol for highly dynamic web applications.

when i said “think for yourself”, i was addressing it exactly to
people like you, no offense, just a tip.

On Fri, Apr 25, 2008 at 09:03:26AM -0300, Alexandre Girao wrote:

(version 0.6.29, but also happens to 0.5.35)
based on connection… geee… this is ugly
This simply means that your application does not conform to FCGI
specification. You should track request id AND connection.

Why do you think that if I will change nginx to conform your application
it will not be “gee… ugly” ?

it can be reused, indeed, this just reinforces my previous paragraph…
that i need to track request state based on the request id

the spec says “the application keeps track of the current state of
each request ID” not “the application keeps track of the current state
of each transport connection”

Your cite is not complete: “the application keeps track of the current
state of each request ID on a given transport connection.” This means
that two connections may have the same request id on the same time.

Actually, your FastCGI server may serve two different frontends those
have no idea about each other existance. They will use the same request
id
range. How will you track their requests using request id only ?

nginx has no full FastCGI support. Yes, I agree completely.
But it conforms to the subset of FastCGI specs.

On Fri, Apr 25, 2008 at 9:26 AM, Igor S. [email protected] wrote:

This simply means that your application does not conform to FCGI
specification. You should track request id AND connection.

Actually, your FastCGI server may serve two different frontends those
have no idea about each other existance. They will use the same request id
range. How will you track their requests using request id only ?

i got it, thanks for the enlightenment… haven’t thinked in this terms
of “request id AND connection”

nginx has no full FastCGI support. Yes, I agree completely.
But it conforms to the subset of FastCGI specs.

right


Igor S.
http://sysoev.ru/en/

thanks again

Hello!

On Fri, Apr 25, 2008 at 09:03:26AM -0300, Alexandre Girao wrote:

(version 0.6.29, but also happens to 0.5.35)
based on connection… geee… this is ugly
the specification is not saying that the webserver can fix the request
id, it simple says that after a request id is over (full life cycle)
it can be reused, indeed, this just reinforces my previous paragraph…
that i need to track request state based on the request id

the spec says “the application keeps track of the current state of
each request ID” not “the application keeps track of the current state
of each transport connection”

No. The spec was quoted above, and it says that “the application
keeps track of the current state of each request ID on a given
transport connection”.

You shouldn’t assume that unrelated requests on different transport
connections may not have equal requestId’s. This violate specs.
Additionally, this makes impossible to use such application from
more than one server even theoretically.

The thing you should track is “connection + requestId”. Anything
less is “simply wrong” ©.

Maxim D.

On Fri, Apr 25, 2008 at 9:55 AM, Maxim D. [email protected]
wrote:

based on connection… geee… this is ugly

Maxim D.

my bad Maxim… you said this just as is in the spec but i completely
dismissed the fact that my fastcgi application can serve various web
servers, perhaps because i never worked this way (small applications),
you guys saved me a lot of a possible headache in the future, indeed,
im enjoying fastcgi even more after realizing this.

thanks Maxim

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs