fastcgi, simply wrong

[Alexandre Girao]

On Fri, Apr 25, 2008 at 9:55 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> Hello!
>
>
>
>  On Fri, Apr 25, 2008 at 09:03:26AM -0300, Alexandre Girao wrote:
>
>
> > On Fri, Apr 25, 2008 at 5:02 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> >
> > > 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.
> > >
> >
> > 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"
> >
>
>  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" (c).
>
>  Maxim Dounin
>
>

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