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

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to