[Web-SIG] Relationship between SCRIPT_NAME and PATH_INFO.

Alan Kennedy pywebsig at alan.kennedy.name
Sun Jan 28 20:07:56 CET 2007


[Graham Dumpleton]
> Should a WSGI adapter for a web server which allows a mount point to
> have a trailing slash specifically flag as a configuration error an
> attempt to use such a mount point given that it appears to be
> incompatible with WSGI?

OK, I'll have a go.

I think the question boils down to the following:

Assume an application mount point of "/application".

If a request is received for

/application

Then it will (and should) be redirected to the URL

/application/

Is that new URL to be interpreted as

SCRIPT_NAME: /application
PATH_INFO:   /

or interpreted as

SCRIPT_NAME: /application/
PATH_INFO:

I think that the WSGI interpretation is the first interpretation, and
the correct one, because it gives correct results when deriving
relative URLs for resources contained within the application.

Is that addressing the question?

[Graham Dumpleton]
> It therefore seems that the idea of the mount point for an
> application having a trailing slash may be incompatible
> with WSGI. Can this be considered to be the case or is there
> some other way one is meant to deal with this?

I don't know about "incompatible", although it obviously creates the
double-slash problem with computed URLs.

Perhaps the Apache "policy" on this issue is influenced by its origins
as a http server for serving hierarchies of directories and files from
a filesystem?

When it comes to CGI though, Apache does the right thing and passes

SCRIPT_NAME: /application
PATH_INFO:   /

to CGI scripts.

I don't know if this provides any insight into whether or not mounting
applications with a trailing slash is an error.

Does that help at all?

Alan.


More information about the Web-SIG mailing list