Hello Neil, thank you for this thread and for how you handled the issue. This was a tricky one to debug and a very important issue for the community. We can all rejoice this is a uwsgi issue and not a web2py one.
There is nothing web2py can do if the web server injects the wrong headers but I will add some client_addr validation and raise HTTP(xxx) if the client_addr is "unknown". massimo On Wednesday, 25 July 2012 11:54:07 UTC-5, Neil wrote: > > I got to the point where I could reproduce this locally using incognito > mode. Looks like it is a known uwsgi bug that was just patched 3 days ago: > > > http://stackoverflow.com/questions/11598935/uwsgi-resends-headers-in-async-mode > > > To anyone else using a recent version of uwsgi - you might want to turn > off async, or you could get some very undesirable behaviour (and angry > users)! > > On Wednesday, July 25, 2012 2:49:48 PM UTC+1, Massimo Di Pierro wrote: >> >> The author of the post below says: >> "These are 2 distinct clients. I opened an incognito session, confirmed >> that no cookie was sent in the headers, and the uwsgi log shows that it >> received the same HTTP_COOKIE." >> >> This could very much be the problem. It would definitively cause the >> behavior you see. >> I still do not understand what uwsgi is doing. Is it proxing cookies? And >> what does facebooks and iDevices have to do with this? >> >> I have a theory. the problems where from iDevices. Probably they are >> going over phone networks. Perhaps they have IPv6 addresses. Perhaps uWSGI >> gets confused by this or by some other weird parameter in the HTTP_HEADER >> coming from these devices. One symptom is that it assigns cliend_addr = >> "unknown" as we have seen before. It is possible that uWSGI by default >> caches cookies from the same client addr. I do not understand why it would >> do that but it could be. Perhaps uWSGI is as fast as it is because it skips >> some proper header parsing. >> >> Massimo >> > --
