IE 7 reports server error after post

[eli.burstein@…]

Internet Explorer 7 reports server error after posting. The form is received but seems that explorer fails to receive the page. If page is reloaded by refresh or finding the ticket you can see the new data updated. This is IE only bug.

We using and quad processor system for trac. I tried to run tracd under single processor by limiting affinity with no change in behavior.

[Christian Boos]

This makes me think about #1168, but it seems you're using tracd so it can't be the same issue.

Are you talking about every change or just edits to big wiki pages? (#6268)

[anonymous]

It happens on every change to:

• wiki pages (any size)
• Tickets (change to any field)

I should point that the post doesn't fail. The data is posted to and updated by tracd. It seems like IE receives some response it considers to be malformed. I can see this by entering the ticket again and I see that all the data is updated. Also there is no error in the trac log.

[bill_beers@…]

I also have a similar configuration (same version, running via tracd), and see the same results. The posts make it to the server (tickets or wiki page changes are made), but the response fails with internal server error.

[mhellspong@…]

I have the same problem with 0.11.3, tracd and IE7. Reproducible every time I tried on different setups using tracd.

After using Wireshark and Fiddler2, I'm fairly certain it is because IE7 (and possibly other versions of IE) in some conditions appends CRLF to a POST (see ​http://support.microsoft.com/kb/823099 and possibly ​http://support.microsoft.com/kb/816405) which are not included in its Content-Length header. Tracd then reads the post data normally, but does not read the added CRLF.

This probably causes the CRLF to be seen as the beginning of the next request, which causes tracd to issue a TCP RESET when it looks illegal.

When I edit the POST:ed data with Fiddler and remove the trailing CRLF it works as expected. The SendExtraCRLF-registry workaround mentioned in the KB articles also works. I have no problems when using IE6 and Firefox 3.

[anonymous]

Replying to mhellspong@…:

I have no problems when using IE6 and Firefox 3.

Just tried editing with the release version of Internet Explorer 8, and it seems to work immediately, and does not seem to need the registry hack (removed the SendExtraCRLF registry hack and rebooted and it still works).

[anonymous]

Some of our users experienced the issue using IE6.

[Christian Boos]

TracStandalone: add --http11 option for server content using HTTP/1.1 protocol version.

[Christian Boos]

Reading ​kb:823099:

Internet Explorer typically sends an extra CRLF in a POST request when it thinks that it is communicating with an HTTP 1.0-based server.

I thought, no wonder that IE thinks it's talking to an HTTP 1.0 server, as this is what we pretend to be ;-)

Please try out the attachment:t8020-http11-r7956.diff​, start tracd with the new --http11 option and see if this improve things.

If nothing else, this should at least improve the response time (up to two times faster, in the common case) :-)

[Christian Boos]

Same as attachment:t8020-http11-r7956.diff​ but with reverse name lookups also disabled when specifying --http11

[Christian Boos]

Sorry, just noticed a copy/paste issue in my first patch, I intended to make TracHTTP11RequestHandler inherit from TracHTTPRequestHandler. This improves the performance even further.

Please test with attachment:t8020-http11-r7956.2.diff​.

[Christian Boos]

That patch seems to also fix the problem of editing big wiki pages with IE7, mentioned in ticket:6268#comment:5. Not only that, but the #3043 issue which came nearly systematically during such attempts for editing big pages goes away as well.

Also marked #7736 as duplicate of this issue. #6534 was possibly also a duplicate.

[Christian Boos]

Hm, /login doesn't work with --http11 :-(

[Christian Boos]

So I've fixed the login, but there's a bunch of other issues (mostly 'Content-Length' related it seems). I'll try to prepare an updated patch soon.

[anonymous]

I can't believe this hasn't been marked as a show stopper. What is happening with this bug?

[Christian Boos]

Work in progress?

[Christian Boos]

In the last version of the patch, the login works fine, as well as a couple of other type of requests which previously failed to set the Content-Length properly. I still have a handful more to fix in the report and changeset modules, but in the meantime I'm very much interested to know if the patch (+ using that new --http11 switch for tracd, of course!) is enough to avoid the problem with IE7 described in this ticket. So please test and give me some feedback.

Also, if all goes well, I think that when porting on trunk, I'll make tracd use HTTP/1.1 by default (and perhaps add a --http10 switch in case the old behavior is desired).

[Christian Boos]

Improved support for HTTP/1.1 in tracd - still not 100% but complete enough for checking this issue

[Simon Walton <s_walton@…>]

I can confirm the latest patch tracd-http11-r8080.diff works with IE7, on 0.11stable. I'm using authentication also and that seems to work just fine. I will be testing it more completely over the next week and will post any issues here. Thanks!

[Christian Boos]

More complete patch committed as r8215.

This change adds HTTP/1.1 support to tracd, which will be used when specifying --http11 on the command-line. r8216 also adds the --http10 option, for forcing HTTP/1.0 to be used, in case the default behavior changes. For now 0.11.5, the default is still 1.0, but if all goes well, I think it will be worth switching the default to 1.1 in further releases.

According to comment:10 and comment:16, using --http11 fixes the problem with IE7 reported here.

[Christian Boos]

FWIW, I just found today that this is a "known issue" for BaseHTTPServer, see ​PythonBug:2126.

[Christian Boos]

Just noticed a problem with 404 responses when —http11 is specified, another missing Content-Length (hopefully the last).

[Christian Boos]

… another missing Content-Length (hopefully the last).

Fixed in r8269.

[Christian Boos]

oops, AJAX requests need to send the Content-Length as well.

[Christian Boos]

Apparently, there was only one place left to fix, done in r8300.