[Web-SIG] Internal redirect using Location with absolute path and status of 200.
The CGI specification allows for a CGI script to return a 'Location' header which refers to a location within the local web server. Quoting the RFC: """If the Location value is a path, then the server will generate the response that it would have produced in response to a request containing the URL""" In Apache this is honoured when the Status returned by the CGI script is also 200. The end result is that rather than sending a redirect back to the web client, Apache will trigger a new sub request against the path (as a GET request) and return the result of that to the web client. Although the WSGI specification doesn't mention any requirement for a WSGI adapter for a web server to do the same thing, it may be an interesting thing to consider for a future version of the WSGI specification. Does anyone know of any WSGI adapter which currently implements this, besides CGI/WSGI adapters which by virtue of CGI specification should implement it? Has anyone used this convention internal to a WSGI stack as a means of performing local redirection, thereby avoiding forcing the client to do the redirect? Does anyone think this would be nice extension for a WSGI adapter written against current specification to implement even if not necessarily portable? Graham ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Internal redirect using Location with absolute path and status of 200.
Graham Dumpleton wrote: > Does anyone know of any WSGI adapter which currently implements this, > besides CGI/WSGI adapters which by virtue of CGI specification should > implement it? Not that I know of. > Has anyone used this convention internal to a WSGI stack as a means of > performing local redirection, thereby avoiding forcing the client to > do the redirect? Nope. I use a hook to the most parent application, and then call in to that manually. > Does anyone think this would be nice extension for a WSGI adapter > written against current specification to implement even if not > necessarily portable? Eh. In the context of mod_wsgi, I think it would be more interesting to provide a WSGI application that called back into Apache (basically wrapping Apache's normal subrequest machinery in a WSGI exterior). -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org | Write code, do good | http://topp.openplans.org/careers ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Internal redirect using Location with absolute path and status of 200.
Ian Bicking wrote: >> Does anyone think this would be nice extension for a WSGI adapter >> written against current specification to implement even if not >> necessarily portable? > > Eh. To add to this, I never found the CGI functionality useful. Why would I do that and not a real redirect? If there's links they'll be broken, because the client and the resource won't agree on what the real request URL was. If the script/app is the consumer, the Location header stuff doesn't work -- you don't get back the response. So it doesn't work for web service style internal requests. If it's something like authentication, that doesn't work either -- you are giving a request path back, which anyone could access, and you haven't added any information to it to specifically permit access (unless there's something in the environment that makes the subrequest clear; I never looked closely enough, nor is it specified). -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org | Write code, do good | http://topp.openplans.org/careers ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Internal redirect using Location with absolute path and status of 200.
On 24/05/07, Ian Bicking <[EMAIL PROTECTED]> wrote: > Graham Dumpleton wrote: > > Does anyone think this would be nice extension for a WSGI adapter > > written against current specification to implement even if not > > necessarily portable? > > Eh. In the context of mod_wsgi, I think it would be more interesting to > provide a WSGI application that called back into Apache (basically > wrapping Apache's normal subrequest machinery in a WSGI exterior). I was trying to avoid as much as possible having mod_wsgi provide any sort of hooks which would allow one to perform actions against internals of Apache. I had two reasons for this. The first reason is that it would only be available when using mod_wsgi and thus an application written to that interface would not then be a portable WSGI application. The second reason is that I can't provide that feature for both modes that mod_wsgi operates in. The first mode I speak of here is 'embedded' mode, which is where everything runs in the Apache child processes just like mod_python and thus has access to all the redirection machinery. The second mode and one for which I wouldn't be able to provide this feature for is 'daemon' mode, which is similar to FASTCGI/SCGI solutions, where the WSGI request handling is done within the context of a separate process. Although this daemon process is forked from the main Apache process and managed by Apache, it is only capable of handling the specific WSGI request handed off to it from the Apache child process that received the request, it cant do internal redirects or other complicated stuff involving internal Apache APIs. Because in 'daemon' mode an application can run as a distinct user and not the Apache user, and because it moves the memory bloat of a WSGI application out of the Apache child processes, this mode is likely to be the preferred way of using mod_wsgi. If the feature weren't to be available in this mode it is sort of questionable whether one should provide it for 'embedded' mode. The 'Location' header based redirect I can though do in both modes no problem, as the 'Location' header redirect would be handled in Apache child process when handling response from daemon process. It can only redirect to a GET request as POST data would have already been consumed as necessary to send that through to the daemon process in case it was required just like if it was a CGI script. In the longer term I am looking at doing an alternate Apache module for using Python similar to mod_python which gives full Apache API access using SWIG rather than hand crafted API like mod_python. This Apache module may be a better vehicle for hosting WSGI application where you want to hook into Apache internals. Thus, mod_wsgi might be seen as average users solution and suitable (safe) for commodity web hosting, whereas this other Apache module I speak of might be seen as more for power users who dedicate Apache instance to the application. Graham ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Internal redirect using Location with absolute path and status of 200.
On 24/05/07, Ian Bicking <[EMAIL PROTECTED]> wrote: > Ian Bicking wrote: > >> Does anyone think this would be nice extension for a WSGI adapter > >> written against current specification to implement even if not > >> necessarily portable? > > > > Eh. > > To add to this, I never found the CGI functionality useful. Why would I > do that and not a real redirect? If there's links they'll be broken, > because the client and the resource won't agree on what the real request > URL was. If the script/app is the consumer, the Location header stuff > doesn't work -- you don't get back the response. So it doesn't work for > web service style internal requests. If it's something like > authentication, that doesn't work either -- you are giving a request > path back, which anyone could access, and you haven't added any > information to it to specifically permit access (unless there's > something in the environment that makes the subrequest clear; I never > looked closely enough, nor is it specified). Understand. Although CGI specifies it, if it isn't in practice useful for much then no point doing it. I'll thus not worry about it unless someone comes along with a very compelling argument of how it may actually be useful. Graham ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
