wfastcgi.py: SCRIPT_NAME, PATH_INFO incorrect

[adamkerz]

According to both the CGI and WSGI standards (https://www.ietf.org/rfc/rfc3875, https://www.python.org/dev/peps/pep-0333/), SCRIPT_NAME should be the path to "application object" (ie. the script) and PATH_INFO the "remainder of the URL's path". But IIS seems to be passing BOTH with the FULL URL!?

To replicate, set up an application called test within the default website and register the wfastcgi handler for use with it. Go to http://server/test/this and both SERVER_NAME and PATH_INFO will be set to 'test/this' but they should be SERVER_NAME='test/', PATH_INFO='this'.

I don't know enough to call this an IIS bug, but it's certainly a wfastcgi bug as it doesn't conform to the WSGI standard. Is there a way to get IIS to do the right thing without modifying wfastcgi? I can't find it.

Using IIS v8.5.9600.16384 on Windows Server 2012 R2 (6.2 build 9200)

[crwilcox]

Are you using https://pypi.python.org/pypi/wfastcgi?
https://github.com/Microsoft/PTVS/wiki/wfastcgi

[adamkerz]

Yep, from PyPI, wfastcgi-2.2

[zooba]

Go to http://server/test/this and both SERVER_NAME and PATH_INFO will be set to 'test/this' but they should be SERVER_NAME='test/', PATH_INFO='this'

Should that be SERVER_NAME='server/' and PATH_INFO='test/this'? Or perhaps SCRIPT_NAME='test/'?

If the latter is what you meant, by my reading of PEP 3333 it should actually be SCRIPT_NAME='<section of path up to the web.config file>' and PATH_INFO='<rest of path>', as that's the best we can do in terms of identifying the app vs. the path. For all of our recommended configurations/templates, this will result in SCRIPT_NAME being empty (which is okay), as we don't suggest non-top-level apps. Also, if you set one up, we don't necessarily have that information when we're parsing the fastcgi packet (I think... could be wrong here).

It'd be great to support handling this properly. Contributions are welcome if you figure out how to do it before we get there.

[adamkerz]

Hi guys,

Thanks for taking an active interest and sorry about the terse, slightly typo-ed initial report, I was quite busy that day!

A bit more context: I'm deploying a Django app into IIS and, on Apache/mod_wsgi, a url such as http://www.example.com/myApp/some/path would be split into SCRIPT_NAME='myApp' and PATH_INFO='/some/path'

So, @zooba, yes, I agree with you that:

it should actually be SCRIPT_NAME='

' and PATH_INFO=''

since, if myApp is an application, the web.config will be stored in the myApp dir. This would pretty much match how Apache/mod_wsgi does it.

Like you, I also couldn't find any params that would tell me where to split the path; there may be a way, but I can't see it.

My solution is to pass another environment variable to the script, SCRIPT_NAME that is then used to set the wsgi param of SCRIPT_NAME (and wsgi.script_name) and modify PATH_INFO (and wsgi.path_info) to remove that part.

In the example above, web.config would contain

  <appSettings>
    <add key="WSGI_HANDLER" value="sirgisCmdb.wsgi.application" />
    <add key="SCRIPT_NAME" value="myApp" />
    ...

and wfastcgi.py would read this from os.environ and modify the IIS provided values of:

SCRIPT_NAME='myApp/some/path'
PATH_INFO='myApp/some/path'

to:

SCRIPT_NAME='myApp'
PATH_INFO='/some/path'

before passing the request through to the WSGI handler.

This works for my Django app and I believe should allow non-top-level apps to whatever level you'd like. Whether it works correctly for all WSGI applications, I don't know. Whether the SCRIPT_NAME should end in the trailing forward slash in other WSGI application, I don't know, but that's easily fixed.

I will fork and provide a pull request unless someone has a better suggestion or knows a better way to do it - it's not a perfect solution, but perfectly workable, I think.

Thoughts?

[zooba]

My only thought is that we'd rather have a configuration-free solution, as then it will work without having to get people to read the documentation first. If specifying SCRIPT_NAME is the workaround that we need to handle it for now, that's fine, provided that when it isn't specified the SERVER_NAME + SCRIPT_NAME + PATH_INFO == original URL constraint holds (which it currently doesn't), presumably with an empty SCRIPT_NAME.

Matching mod_wsgi behaviour is ideal, and we try and do that as a general rule.

[adamkerz]

Agreed, so perhaps SCRIPT_NAME should ALWAYS be empty if PATH_INFO is the full path, unless the user configures an alternate SCRIPT_NAME. I don't think that this will break existing code, but who know!?!? If I knew IIS or mod_wsgi better, I would be more confident in suggesting this.

I can't see another way without doing this bit of configuration (mind you, it just doesn't work at all right now, better a user can get it to work, even if they have to read some doco).

Will patch my fork and create a pull request for further discussion in the next day or two.

[adamkerz]

Created pull request: #1037

What more is needed to get this integrated and published to PyPI? Forgive my ignorance of the wider project, I've only used the WFastCGI component.

[crwilcox]

@adamkerz, basically we need to look at your change and make sure we agree with the solution. Once we has that out and merge this we will need to push this to PyPI as a new version. The only possible thing left on your end is to make corrections if any are pointed out by the team.

FYI: Most of the team is out until the new year so it may take a bit longer than usual just because of that.

[adamkerz]

No problem, I've deployed my app to prod with a minor manual step in there to put my version of wfastcgi.py in place, but I shouldn't need to touch it now, so I'm in no rush. Just wanted to make sure I wasn't the blocker on the issue. Happy to take any suggestions and make any changes as requested, when you get a chance to look at it.

[zooba]

It's merged. As I mentioned on the PR, there's more that I want to do with wfastcgi before making a release (such as separating to a new repo, tests, etc.) but it's fairly easy to substitute a separate wfastcgi.py into a deployment.

[rajivharris]

Thanks @adamkerz !
This saved my life, last two weeks I was struggling to deploy a django application because of the IIS PATH_INFO issue. I replaced the wfastgi 2.2 with your PR and now it works just like that. Love open source!