Trac on IIS - redirect problems.

[josh_robb@…]

This has taken 3 days to trac (wink) down. GRRRRRRRRR - it's not your fault - it's MS's crazy CGI implementation.

If you can manage to get Trac installed and running on IIS (see tickets #693 #692) then you will find that viewing pages (http GET's) works correctly but any attemt to perform a http POST will stall the server or result in Trac error messages.

Symptoms

• " Sorry, Cannot create new version, this page has already been modified by someone else." - for the Wiki.
• 10's - 100's of identical tickets created when you submit the new ticket form.
• IIS gets an stack overflow. (i've not seen this but it's been reported and seems likely).

The cause is this: ​http://support.microsoft.com/default.aspx?scid=kb;en-us;221154

Which is bizzarly cryptic but basically - if you watch network traces of the post occuring you will never see the 302 redirect come back from the server. The reason is because IIS issues the GET request on the serverside if the Location: header is relative. This results in an infinate loop for tickets and an write conflict for Wiki pages (version mismatch).

The work around I have discovered is as follows:

in core.py

    class Request:
        def redirect(self, url):

add the following line:

            #the http://servername bit only! - i.e. no script path etc. 
            base_url = '%s://%s' % ("http", os.getenv('SERVER_NAME'))

change the following:

            self.send_header('Location', burl + url)

This forces the Location: header to be absolute which keeps everything working.

I know this is rubbish. It will break for HTTPS and really the base_url code should be moved into the Request class (?? maybe? ) so that all the base_url logic is in one place.

[Jonas Borgström]

Great work!

You're right, their cgi implementation seems really broken. I hope we can add a workaround for this before 0.8.

[josh_robb at fastmail.fm]

Sorry - I should mention that the SVN intergration is still totally stuffed. I haven't even begun to look into this. I probibally won't have time until I get back from holiday @ the end of the month.

[josh_robb at fastmail.fm]

whops. Milestone reset.

[Matthew Good <matt-good.net>]

Hmmm, well it's also missing the port number. Also, I tend to try to use the urlparse module when building urls, as that's what it's there for.

[j.siddle at warwick.ac.uk]

IIRC REDIRECT as a response to POST is not technically allowed, although it is commonplace. Specifically, a JAVA client can have trouble POSTing if the reponse is redirected to a relative url. I found this out while writing an automatic ticket submission routine in a java application. A workaround involved writing custom hooks to handle the redirection. It seems to work fine with absolute URLs however. I'm not exactly sure about what the official standards say, or if it is Sun/MS who have buggy software, but perhaps someone should check what the standards actually allow?

[Jonas Borgström]

Moving forward until we have a "real" solution for this…

[kalab@…]

I had the same problem with Xitami/2.5c2: ​http://www.imatix.com on Windows XP SP1.

The workaround above fixes this.

[markus]

FYI: Josh's changes mentioned above don't fix the problems on my IIS5 when using [1274]. I did not yet have a chance to investigate why.

[markus]

As j.siddle already said: A "REDIRECT as a response to POST is not technically allowed".
See RFC2616 14.30 and the python sources. In urllib2.py there can be found the following comment: "Strictly (according to RFC 2616), 302 in response to a POST MUST NOT cause a redirection without confirmation from the user (of urllib2, in this case). In practice, essentially all clients do redirect in this case, so we do the same." So, MS' cgi implementation is not broken. IIS acts according to the specs.

[Christopher Lenz]

The specs don't say anything about treating redirects to non-absolute URLs as "internal" redirects, which is the problem here. Arguably, this is totally broken behavior by IIS. The fix to this issue is to always use absolute URLs for the Location header on redirects.

In an ideal world, we'd use "307 See Other" to redirect after POST requests, but I have no idea how well supported that is by user agents. Normal redirects work just fine in the meantime.

[Christopher Lenz]

Fixed in [1330].