Added validation for request.client in trunk On Wednesday, 25 July 2012 16:29:45 UTC-5, Massimo Di Pierro wrote: > > 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 >>> >>
--
