[Web-SIG] Who is responsible for SCRIPT_NAME?

[Ian Bicking]

Robert Brewer wrote:
> Phillip J. Eby wrote:
> 
>>The only time you should set SCRIPT_NAME to "" is if the 
>>application object being executed is mounted at the server
>>root.  So, this is correct behavior for a server like
>>wsgiref's SimpleHTTPServer, which does not provide any
>>mount points.  If your server implements mount points, you 
>>should indeed set SCRIPT_NAME to appropriate path for
>>the app being executed.
> 
> 
> Thanks; that makes sense, and is how I've always interpreted the spec.
> 
> 
>>As far as I can tell, the only confusion in the conversation 
>>was that Ian was trying to point out that middleware can be
>>used to implement mount points, rather than building mount
>>points directly into the server.  That is, he was making an
>>implementation suggestion that a server (especially one
>>destined for stdlib inclusion) can be simpler if it just
>>provides a single mount point at the root and leaves the
>>routing to a middleware component -- which of course would
>>then be reusable and interchangeable.  And if that wasn't
>>what he meant by saying the server should set SCRIPT_NAME
>>to "", then he's wrong.  ;)
> 
> 
> Here's my continuing issue: if we allow middleware to implement mount
> points, then your first statement (above) needs to be modified to:
> 
>     The only time [the origin server] should set SCRIPT_NAME
>     to "" is if the application object being executed is
>     mounted at the server root OR you use a dumb server
>     and instead rely on middleware to do the routing.

I can mount a routing middleware anywhere.  So I can have /blog routed 
to my WSGI application, and then have /blog/admin routed one place and 
/blog/ routed another place.  Using the dispatching example I gave 
earlier, that would be {'/admin': admin_app, '/': other_app}, as it only 
routes based on the PATH_INFO.  (It can be okay to route based on 
SCRIPT_NAME too, but you are more likely to encounter confusing 
situations in that case)

Of course, it is also always the prerogative of the developer to fix 
something that is broken, and some servers do pass an incorrect 
SCRIPT_NAME, and some protocols have no way to express SCRIPT_NAME.  It 
is best to fix this as early as possible in the request chain, and then 
assume it is correct from there on.

>>I don't think the *spec* is ambiguous on this, but if you can 
>>point out a bit that makes it seem uncertain, please feel
>>free to suggest additional or alternate wording.  Thanks.
> 
> 
> SCRIPT_NAME
>     The initial portion of the request URL's "path" that corresponds to
> the application object, so that the application knows its virtual
> "location". This may be an empty string, if the application corresponds
> to the "root" of the server.
> 
> This section is becoming increasingly ambiguous to me. If you're using
> middleware to do the routing, I don't know whether "the application"
> refers to the middleware or to the end app which the middleware wraps.
> 
> 1. If "the application" refers to the end app or framework, then I think
> many people (me included) are expecting that whatever SCRIPT_NAME is set
> by the origin server should pass through unchanged to the end app. If
> true, then it seems to me we're saying that this part of the spec simply
> doesn't apply to the origin-server-to-routing-middleware part of the
> conversation, because the origin server doesn't know whether the
> application corresponds to the "root" of the server or not (only the
> middleware knows). So the first half of the WSGI conversation
> (server-to-middleware) doesn't strictly follow the spec.

In the case of routing middleware there are two WSGI requests happening. 
  The first is the server talking to the middleware (the middleware is 
the application in this case), and the second is the middleware talking 
to the application (the middleware is a server in this case).  "server" 
always means "the thing that is calling the application", and 
"application" always means "the thing being called by the server".  The 
two names refer to a relationship during a particular call sequence, 
nothing more.

> I don't mind that, but the spec could be clearer by saying SHOULD or
> MUST in the above block, and (if it's SHOULD instead of MUST) detailing
> the "middleware routing scenario", in which the origin server isn't
> responsible to set SCRIPT_NAME to the end application's virtual location
> if middleware is going to do that instead.
> 
> 2. "The application" could refer to the routing-middleware (because it
> implements both the application side and the server side of the spec).
> In other words, to the origin server, the routing-middleware's callable
> is the only WSGI application to care about, and it's always "mounted at
> root" so SCRIPT_NAME can always be "". I haven't adopted this
> interpretation, because in my mind, middleware isn't mounted
> anywhere--it's a filter for the end app(s).

The middleware is an application -- the server doesn't and can't know 
the difference between middleware and a terminal application.  The 
distinction is fuzzy anyway, as it is fairly easy to find yourself 
writing something that plays both roles (application and middleware). 
In turn, an application can't know if the thing calling it is a "server" 
that is actually talking to a socket, or some middleware that is passing 
along a request.



-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org