Edgewall Software
Modify

Opened 11 years ago

Closed 10 years ago

#8020 closed defect (fixed)

IE 7 reports server error after post

Reported by: eli.burstein@… Owned by: Christian Boos
Priority: high Milestone: 0.11.5
Component: web frontend/tracd Version: 0.11-stable
Severity: major Keywords: IE tracd iexplorer7
Cc: trac-ja@… Branch:
Release Notes:
API Changes:

Description

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.

Attachments (3)

t8020-http11-r7956.diff (2.5 KB ) - added by Christian Boos 10 years ago.
TracStandalone: add --http11 option for server content using HTTP/1.1 protocol version.
t8020-http11-r7956.2.diff (2.5 KB ) - added by Christian Boos 10 years ago.
Same as attachment:t8020-http11-r7956.diff but with reverse name lookups also disabled when specifying --http11
tracd-http11-r8080.diff (5.0 KB ) - added by Christian Boos 10 years ago.
Improved support for HTTP/1.1 in tracd - still not 100% but complete enough for checking this issue

Download all attachments as: .zip

Change History (25)

comment:1 by Christian Boos, 11 years ago

Keywords: needinfo added

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)

comment:2 by anonymous, 11 years ago

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.

comment:3 by bill_beers@…, 11 years ago

Keywords: needinfo removed

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.

comment:4 by mhellspong@…, 11 years ago

Version: 0.11.2.10.11-stable

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.

comment:5 by trac-ja@…, 11 years ago

Cc: trac-ja@… added
Keywords: iexplorer7 added

in reply to:  4 comment:6 by anonymous, 11 years ago

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).

comment:7 by anonymous, 10 years ago

Some of our users experienced the issue using IE6.

by Christian Boos, 10 years ago

Attachment: t8020-http11-r7956.diff added

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

comment:8 by Christian Boos, 10 years ago

Milestone: 0.11.5
Owner: set to 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) :-)

by Christian Boos, 10 years ago

Attachment: t8020-http11-r7956.2.diff added

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

comment:9 by Christian Boos, 10 years ago

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.

comment:10 by Christian Boos, 10 years ago

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.

comment:11 by Christian Boos, 10 years ago

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

comment:12 by Christian Boos, 10 years ago

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.

comment:13 by anonymous, 10 years ago

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

comment:14 by Christian Boos, 10 years ago

Work in progress?

comment:15 by Christian Boos, 10 years ago

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).

by Christian Boos, 10 years ago

Attachment: tracd-http11-r8080.diff added

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

comment:16 by Simon Walton <s_walton@…>, 10 years ago

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!

comment:17 by Christian Boos, 10 years ago

Resolution: fixed
Status: newclosed

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.

comment:18 by Christian Boos, 10 years ago

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

comment:19 by Christian Boos, 10 years ago

Resolution: fixed
Status: closedreopened

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

in reply to:  19 comment:20 by Christian Boos, 10 years ago

Resolution: fixed
Status: reopenedclosed

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

Fixed in r8269.

comment:21 by Christian Boos, 10 years ago

Priority: normalhigh
Resolution: fixed
Status: closedreopened

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

comment:22 by Christian Boos, 10 years ago

Resolution: fixed
Status: reopenedclosed

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to as closed The owner will be changed from Christian Boos 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.