Ah, so at least now I know where the additional request/response ended up! There is still something puzzling going on, however.
If we look at the web.http.redirect function, we can see that it starts: if url.startswith("/"): newloc = web.ctx.homepath + url else: newloc = url I can't really see how this is reconciled with RFC2616's requirement that the value of the Location header be an absolute URI (including a scheme and a host, etc). I checked the docs at <http://webpy.infogami.com/docs> and saw that web.ctx.homepath is not documented, so I am not certain what it is supposed to be set to. But even if web.ctx.homepath is supposed to be a full absolute URI, if the redirection target does not start with a slash then an absolute URI won't be generated. Anyway, it seems that with SCGI, web.ctx.homepath is only set to an empty string, which I assume is not correct! :) While debugging this, I created a URL handler that prints out the contents of web.ctx and compared its output between running the application with CGI and with SCGI. The differences are as follows: CGI: web.ctx.home = 'http://blah.com/cgi-bin/foo' web.ctx.homepath = '/cgi-bin/occs' SCGI: web.ctx.home = 'http://blah.com' web.ctx.homepath = '' So, it seems to be that the 'redirect' function would be more correct if it did this: if url.startswith ('/'): newloc = urllib.urljoin (web.ctx.home, url) else: newloc = urllib.urljoin (web.ctx.home + os.path.dirname (web.ctx.path), url) What do you think? -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078
signature.asc
Description: This is a digitally signed message part