Cache problem?

Server NGINX
1

I’m running a Perl/PSGI CGI::Application app on nginx via proxy_pass to
Starman. The app logs form fields to a database and retrieves a
resultset which is served up via Template Toolkit. Running on Apache as
a plain vanilla CGI without the PSGI layer I can submit the form, press
the Back button when the resultset is returned and re-hit the submit
button, all within a second or 2 without any errors. However, with nginx

  • Starman the same app produces a random number of successful responses
    then returns an error page from the app as if there were 1 form field
    too many. It looks like some kind of cached response because even if I
    remove the module which runs this part of the app I still see the same
    app-generated error page. Since both nginx and Starman are returning a
    HTTP body there are no errors in the logs of either daemon to work with.

gvim

2

On 5/25/11, gvim [email protected] wrote:

I’m running a Perl/PSGI CGI::Application app on nginx via proxy_pass to
Starman. The app logs form fields to a database and retrieves a resultset
which is served up via Template Toolkit. Running on Apache as a plain
vanilla CGI without the PSGI layer I can submit the form, press the Back
button when the resultset is returned and re-hit the submit button, all
within a second or 2 without any errors. However, with nginx + Starman the
same app produces a random number of successful responses then returns an
error page from the app as if there were 1 form field too many. It looks
like some kind of cached response because even if I remove the module which
runs this part of the app I still see the same app-generated error page.

It’s probably not related to caching whatsoever unless there is a
proxy_cache somewhere in the server block.

Since both nginx and Starman are returning a HTTP body there are no errors
in the logs of either daemon to work with.

How about response status?

Anyway, it might be a long shot, but have you tried switching Starman
to a different PSGI server, like Twiggy or Feersum? After all PSGI is
a relatively new thing for perl and not that widely used.

3

On 25/05/2011 00:39, Alexandr G. wrote:

How about response status?

All 200. The app is returning HTTP content so I don’t expect to see any
errors on the logs of nginx or Starman.

Anyway, it might be a long shot, but have you tried switching Starman
to a different PSGI server, like Twiggy or Feersum? After all PSGI is
a relatively new thing for perl and not that widely used.

Of the ones you’ve listed Starman is the more established. My ngxing
vhosts file has this kind of setup:

server {
root /var/www/html/myapp/pub;
server_name myappserver;
location ~ .psgi {
gzip off;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://127.0.0.1:9000;
}
}

… with Starman running on 127.0.0.1:9000

PSGI/Plack is THE big thing in Perl right now so it’s actually getting a
lot of use, especially within the CGI::Application, Dancer and Catalyst
communities.

gvim

4

On 25/05/2011 01:52, Alexandr G. wrote:

There is nothing wrong with your nginx setup. So there is a good
chance that either PSGI server or your application does this.

I just switched it to nginx + FastCGI/cgi-wrap.pl and it ran
consistently without errors but was dog slow compared with plain vanilla
Apache/CGI. Don’t get it.

gvim

5

On 5/25/11, gvim [email protected] wrote:

Of the ones you’ve listed Starman is the more established.
My ngxing vhosts file has this kind of setup:

There is nothing wrong with your nginx setup. So there is a good
chance that either PSGI server or your application does this.