Fastcgi bug when doing something a little tricky

Hi folks,

Ive just found a bug/feature when using fastcgi in a slightly unusual
manner.

nginx version: nginx/0.6.31

http://websiteurl/article.php

works fine

however if you do

http://websiteurl/article.php/blah/blah

It will still run article.php like i want it to do however depending on
the
length of html the script it runs it multiple times

eg. if I add
exec("/bin/echo 1 >> /data/www/test");
to the top of article.php and go to

http://websiteurl/article.php

it returns


1


however if i go to
http://websiteurl/article.php/1/

it returns


1
1
1
1
1
1
1
1
1
1


Its a bit of a problem for what im trying to do as i would ideally like
to
have
http://websiteurl/article/id/name/etc
and have it process article as a php script

Kingsley F.
Technical Leader Content Services / Content Management Group

=============================================
Internode Systems Pty Ltd

PO Box 284, Rundle Mall 5000
Level 5 150 Grenfell Street, Adelaide 5000
Phone: +61 8 8228 2978
Fax: +61 8 8235 6978
Web: http://www.internode.on.net
http://games.internode.on.net

post your php script

are you sure it’s not doing some sort of internal or external redirect
that you’re just not seeing happen?

Check the value of

proxy_read_timeout

We’ve had sporadic issues with double posts to comments and other
‘should not happen’ issues even though we’ve debounced all the buttons
for a while now. Until now I’ve put it down to PEBKAC but thinking
about your issue I wonder if its actually a problem with my config.
What could be happening is your request is being queued on more than
one upstream. Even though nginx discards the responses from backends
that is has timed out, that does not roll back the effects of those
upstreams that have already processed the request, and being a POST
request it is likely that it will be some kind of database modification.

I had a quick hack at constructing a config which will attempt GETS
multiple times and POSTS only once.

location /controller/update {
if ($request_method == ‘POST’) {
break;
proxy_pass http://mongrel_post;
}
proxy_pass http://mongrel_get;
}

upstream mongrel_get {
localhost:8080 fail_timeout=0;
localhost:8081 fail_timeout=0;
}

upstream mongrel_post {
localhost:8080 max_fails=1 fail_timeout=0;
localhost:8081 max_fails=1 fail_timeout=0;
}

Igor, could you see a need for a proxy configuration variable that
treats Non-idempotent specially.

Cheers

Dave

im not using a proxy however I have

fastcgi_read_timeout 600;

secondly the code on that page that i was testing was the one line of
php to
do the echo and the rest was just html i copy pasted from a random
website.

Kingsley


From: “Dave C.” [email protected]
Sent: Saturday, July 05, 2008 5:29 PM
To: [email protected]
Subject: Re: fastcgi bug when doing something a little tricky

i think you might be on to something,

The site is still very much in dev, so there might be a couple of
invalid
links showing up, ill check and report back.

Kingsley


From: “proforg” [email protected]
Sent: Sunday, July 06, 2008 2:25 AM
To: [email protected]
Subject: Re: fastcgi bug when doing something a little tricky

Hi !

On Sat, Jul 5, 2008 at 1:41 PM, Kingsley F.
[email protected] wrote:

im not using a proxy however I have

fastcgi_read_timeout 600;

secondly the code on that page that i was testing was the one line of php to
do the echo and the rest was just html i copy pasted from a random website.

Please check carefully access log for this virtual host - may be this
“random html” code loading some kind of images etc and these requests
are in turn processed by fastcgi ?

Thanks Proforg,

It turned out to be our web developer not adding the ‘/’ on the start of
all
his image links when i was testing the original code.

I guess im the noob on this one for not noticing during testing.

Kingsley


From: “Kingsley F.” [email protected]
Sent: Sunday, July 06, 2008 5:21 AM
To: [email protected]
Subject: Re: fastcgi bug when doing something a little tricky

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