Edgewall Software

Opened 15 years ago

Closed 15 years ago

#697 closed defect (fixed)

Trac on IIS - redirect problems.

Reported by: josh_robb@… Owned by: Christopher Lenz
Priority: high Milestone: 0.9
Component: general Version: 0.7.1
Severity: blocker Keywords: IIS redirect CGI windows
Cc: josh_robb@… Branch:
Release Notes:
API Changes:

Description (last modified by Christopher Lenz)

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.


  • " 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.

Attachments (1)

.2 (0 bytes ) - added by anonymous 14 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 by Jonas Borgström, 15 years ago

Keywords: win32 added
Milestone: 0.8

Great work!

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

comment:2 by josh_robb at fastmail.fm, 15 years ago

Milestone: 0.8

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.

comment:3 by josh_robb at fastmail.fm, 15 years ago

Milestone: 0.8

whops. Milestone reset.

comment:4 by anonymous, 15 years ago

Resolution: fixed
Status: newclosed

comment:5 by anonymous, 15 years ago

Resolution: fixed
Status: closedreopened

comment:6 by Matthew Good <matt-good.net>, 15 years ago

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.

comment:7 by j.siddle at warwick.ac.uk, 15 years ago

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?

comment:8 by Jonas Borgström, 15 years ago

Milestone: 0.80.9

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

comment:9 by daniel, 15 years ago

Keywords: windows added; win32 removed
Priority: highestlow

comment:10 by kalab@…, 15 years ago

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

The workaround above fixes this.

comment:11 by markus, 15 years ago

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.

comment:12 by markus, 15 years ago

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.

comment:13 by Christopher Lenz, 15 years ago

Description: modified (diff)
Owner: changed from Jonas Borgström to Christopher Lenz
Status: reopenednew

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.

comment:14 by Christopher Lenz, 15 years ago

Description: modified (diff)
Priority: lowhigh
Status: newassigned

comment:15 by Christopher Lenz, 15 years ago

Resolution: fixed
Status: assignedclosed

Fixed in [1330].

by anonymous, 14 years ago

Attachment: .2 added

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Christopher Lenz.
The resolution will be deleted. Next status will be 'reopened'.
to as closed The owner will be changed from Christopher Lenz to the specified user.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.