Yes exactly. Fast hotfix was setting maximum-requests=1. Final bugfix
was to move headers={} to contructor to avoid persistent state, then
use full URLs in Location header.Always must be carefull with persistent data between requests :-) On Mar 17, 11:02 pm, Graham Dumpleton <[email protected]> wrote: > 2011/3/17 Pavel Schön <[email protected]>: > > > > > > > Problem was more complex. > > > There was Response class like this: > > > class Response(object): > > headers = {} > > > Since headers dictionary was defined at the class level, it was shared > > between instances. I did normal redirect 301 with 'Location' header > > set-until this time it was OK. > > > But after next request to this daemon process, 'Location' header was > > still here. I did response 200 OK with Location header set. This > > triggered apache to interpret this response as internal redirect. > > > So this daemon process was messed up with 'Location' header until > > server restart. As a consequence, website was behaved very randomly > > (depending, which daemon process served the response). Broken daemon > > process was always serving the content of the page in 'Location' > > header. > > Okay, so you did hit the 200/Location feature of mod_wsgi daemon mode. > That that feature for internal redirect exists isn't well publicised, > only being mentioned in change notes for mod_wsgi verison 3.0. That > feature also only works for daemon mode and not embedded mode. > > Good thing you have worked it out. > > Graham > > > > > 2011/3/17 Graham Dumpleton <[email protected]>: > >> Do you mean Redirect/RedirectPermanent/RedirectTemp directives, or > >> since URL mentions CGI, a 200/Location response from CGI to force a > >> local internal redirect? > > >> Graham > > >> On 17 March 2011 12:39, diverman <[email protected]> wrote: > >>> Hi. > > >>> This problem is solved. It was caused by doing redirects wrong way. > >>> They were interpreted as apache internal redirects and then > >>> environment variables were prefixed with REDIRECT_. > > >>> Thanks and bye. > > >>> On Mar 16, 11:33 pm, diverman <[email protected]> wrote: > >>>> I'm not at work, but I feel, that unexpected redirect is caused by > >>>> using paths instead of full URL, when doing redirects. > > >>>>http://stackoverflow.com/questions/1390512/apache-cgi-redirect-to-abs... > > >>>> We will see tomorrow... > > >>>> On Mar 16, 5:36 pm, Graham Dumpleton <[email protected]> > >>>> wrote: > > >>>> > There has to be some sort of redirect/rewrite occurring as the > >>>> > REDIRECT_ prefixes are inserted specifically when that occurs. > > >>>> > Can you perhaps send me your whole Apache configuration direct to me > >>>> > in private email so I can look at it and see what other directives you > >>>> > are using which might be triggering it. > > >>>> > Use Graham.Dumpleton at gmail address. > > >>>> > I have to go get on a plane in a few minutes and will look at it later > >>>> > tonight or tomorrow when get Internet again. > > >>>> > Graham > > >>>> > On 16 March 2011 10:37, diverman <[email protected]> wrote: > > >>>> > > Hi Graham. > > >>>> > > I've investigated, that error happens, when most of environment > >>>> > > variables are prefixed with REDIRECT_. Sometimes they are prefixed > >>>> > > with REDIRECT_REDIRECT_REDIRECT_. > > >>>> > > So I get environment like this: > > >>>> > > [Wed Mar 16 10:09:49 2011] [error] HTTP_USER_AGENT: 'Wget/1.11.4 Red > >>>> > > Hat modified' > >>>> > > [Wed Mar 16 10:09:49 2011] [error] PATH_INFO: '/wrong-page/' > >>>> > > [Wed Mar 16 10:09:49 2011] [error] REDIRECT_PATH_INFO: '/requested- > >>>> > > page/' > >>>> > > [Wed Mar 16 10:09:49 2011] [error] REDIRECT_mod_wsgi.callable_object: > >>>> > > 'application' > >>>> > > [Wed Mar 16 10:09:49 2011] [error] REDIRECT_mod_wsgi.handler_script: > >>>> > > '' > >>>> > > [Wed Mar 16 10:09:49 2011] [error] REDIRECT_mod_wsgi.input_chunked: > >>>> > > '0' > >>>> > > [Wed Mar 16 10:09:49 2011] [error] REDIRECT_mod_wsgi.listener_host: > >>>> > > '' > >>>> > > .... > > >>>> > > In short: browser requested page "/requested-page/", but application > >>>> > > received in PATH_INFO "/wrong-page/". Requested page is now under key > >>>> > > REDIRECT_PATH_INFO. In access log is: > > >>>> > > x.x.x.x - - [Wed Mar 16 10:09:49 2011] "GET /requested-page/ > >>>> > > HTTP/1.1" > >>>> > > 200 163855 > > >>>> > > In access_log aren't any 301 or 302 responses. > > >>>> > > Thanks for advice. > > >>>> > > Pavel > > >>>> > > On Mar 14, 8:59 pm, Graham Dumpleton <[email protected]> > >>>> > > wrote: > >>>> > >> On 14 March 2011 15:54, diverman <[email protected]> wrote: > > >>>> > >> > Hi, > > >>>> > >> > I'm running apache 2.2.3 and mod_wsgi in daemon mode. Sometimes I > >>>> > >> > get > >>>> > >> > in access_log some path (as requested from browser), but > >>>> > >> > application > >>>> > >> > in environ receives completely different PATH_INFO (which is also > >>>> > >> > valid in this app). There aren't any other modules or rewrite > >>>> > >> > rules. > > >>>> > >> > Configuration: > > >>>> > >> > <VirtualHost ...> > >>>> > >> > WSGIDaemonProcess example display-name=%{GROUP} user=example > >>>> > >> > group=example processes=4 > >>>> > >> > threads=1 > >>>> > >> > WSGIProcessGroup example > >>>> > >> > WSGIScriptAlias / /some/path/example.wsgi > >>>> > >> > </VirtualHost> > > >>>> > >> > Do you have any idea, what could it be? > > >>>> > >> Can you provide actual examples of how it appears in access log and > >>>> > >> what SCRIPT_NAME and PATH_INFO are from application. > > >>>> > >> If you replace WSGI application with simple test application such > >>>> > >> as: > > >>>> > >>http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Displaying_... > > >>>> > >> Does it still happen. Ie., verify that in no way related to your > >>>> > >> specific web application. > > >>>> > >> Graham > > >>>> > > -- > >>>> > > You received this message because you are subscribed to the Google > >>>> > > Groups "modwsgi" group. > >>>> > > To post to this group, send email to [email protected]. > >>>> > > To unsubscribe from this group, send email to > >>>> > > [email protected]. > >>>> > > For more options, visit this group > >>>> > > athttp://groups.google.com/group/modwsgi?hl=en. > > >>> -- > >>> You received this message because you are subscribed to the Google Groups > >>> "modwsgi" group. > >>> To post to this group, send email to [email protected]. > >>> To unsubscribe from this group, send email to > >>> [email protected]. > >>> For more options, visit this group > >>> athttp://groups.google.com/group/modwsgi?hl=en. > > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "modwsgi" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]. > >> For more options, visit this group > >> athttp://groups.google.com/group/modwsgi?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "modwsgi" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/modwsgi?hl=en. -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
