In deploying my Django 1.4 site to Azure, I've run into an issue with urls containing query strings.

The issue appears to be that certain environment variables used to transfer request info to my site is not being set correctly. Specifically PATH_INFO and QUERY_STRING.

PATH_INFO contains the full path after the hostname, including the query string, instead of just the path without any query string.

i.e. if the full url were www.example.com/test/user/?id=1 PATH_INFO contains /test/user/?id=1 instead of /test/user/

QUERY_STRING meanwhile is empty, rather than containing ?id=1

As a result, any url with a query string fails to resolve correctly because my urlconf is considering the query string as part of the url and so nothing matches. I suspect that a secondary issue would also be that if the url could resolve to something valid, any code depending on the query string would also fail since QUERY_STRING is not populated.

I'm using wfastcgi.py, which comes with the Python27 install present on an Azure website by default in D:/Python27/scripts/wfastcgi.py. I'm assuming this is the same wfastcgi.py found on the Downloads page here; which is why I figured I'd post my issue here.

I'm not certain if the issue lies with the IIS server in Azure or with the wfastcgi.py handler, or if this is even expected behaviour perhaps. I'm looking at the wfastcgi.py file now to see if I can further figure out how my issue might be occurring and how to fix it, but in the meantime if someone here has more knowledge about wfastcgi.py and/or IIS as it relates to Azure and can chime in, that would be very helpful.

I have a stackoverflow post about this issue as well if anyone here is a stackoverflow user and feels like answering there.

EDIT: I should probably also note that I followed this tutorial in setting up the site initially: http://www.windowsazure.com/en-us/develop/python/tutorials/web-sites-with-django/ since it seems to be the recommended method of using Django on Azure and was the instruction I used for setting up wfastcgi.py as my handler.

Partial mistake on my part. In attempting to fix my issue, I had a Web.config file in my wwwroot directory that was attempting to rewrite the URL. It seems to have been stripping the QUERY_STRING (my initial issue as the stackoverflow post shows is that I was getting two query strings showing up) and then when looking into wfastcgi.py I forgot to remove the web.config file first.

Without that file, QUERY_STRING does contain the query string parameters. However, the PATH_INFO variable still also contains the query string appended to the end of the path, so that seems to be the root of my issue.

I could try and figure out how to modify wfastcgi.py to strip the query string from PATH_INFO and then use that custom version of the file as my handler, but considering the one I'm currently using is the default handler built in to Azure and recommended by the Azure tutorial for Django sites, it might be a more broadly important issue; assuming I'm not the only person experiencing it.

Thanks for the report. This may be a problem with wfastcgi.py. Don't take this as an official recommended answer just yet, but I made the following change to the wfastcgi.py from the downloads on codeplex:

find this code:

            if 'HTTP_X_ORIGINAL_URL' in record.params:
                # We've been re-written for shared FastCGI hosting, send the original URL as the PATH_INFO.
                record.params['PATH_INFO'] = record.params['HTTP_X_ORIGINAL_URL']

add this right after:

            # PATH_INFO is not supposed to include the query parameters, so remove them
            record.params['PATH_INFO'] = record.params['PATH_INFO'].split('?')[0]

I published the modified wfastcgi.py with my site and configured the web site to use that one instead of the one installed on azure. That helped make PATH_INFO correct in the scenario I've tested, but not I'm not sure what else I could have broke. We'll let you know when we have more info. Thanks!

Thanks for the workaround. I tried it out and it also works for me. I'll use the modified wfastcgi.py for now and hopefully something can be done about the default wfastcgi.py handler file at some point.

Thanks for the help!

We will be updating the default wfastcgi.py once we can get some of our new functionality tested with this change. We'll let you know when that happens.

Edit:
Added issue to tracker: http://pytools.codeplex.com/workitem/1060