12 messages in ru.sysoev.nginxRe: fastcgi, simply wrong| From | Sent On | Attachments |
|---|---|---|
| Alexandre Girao | Apr 24, 2008 9:11 pm | |
| Maxim Dounin | Apr 25, 2008 1:02 am | |
| Manlio Perillo | Apr 25, 2008 2:58 am | |
| Igor Sysoev | Apr 25, 2008 3:47 am | |
| Igor Sysoev | Apr 25, 2008 4:24 am | |
| Alexandre Girao | Apr 25, 2008 5:03 am | |
| Alexandre Girao | Apr 25, 2008 5:08 am | |
| Alexandre Girao | Apr 25, 2008 5:18 am | |
| Igor Sysoev | Apr 25, 2008 5:26 am | |
| Alexandre Girao | Apr 25, 2008 5:41 am | |
| Maxim Dounin | Apr 25, 2008 5:55 am | |
| Alexandre Girao | Apr 25, 2008 6:05 am |
| Subject: | Re: fastcgi, simply wrong | |
|---|---|---|
| From: | Maxim Dounin (mdou...@public.gmane.org) | |
| Date: | Apr 25, 2008 5:55:22 am | |
| List: | ru.sysoev.nginx | |
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
<mdou...@public.gmane.org> 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