IE5 / Medusa bug?
Tempting fate by claiming a bug...but although I'm sure I'm at fault here, there's no sensible reason for the results I'm getting. When I view one of several different pages with IE5, the last 11 bytes don't reach the browser. I've got a couple of other people to try it out. One of them reported the same symptoms, the other didn't. I don't get it with Netscape. I'd *really* appreciate it if anyone who has IE5 could have a go at http://test.jamkit.com and let me know (you can tell if the bug's happened if the source ends abruptly with something like '</ta'). Things I've deduced: - http://test.jamkit.com/index_html works :S - It's not related to the bad HTML in that example page (I've tried pages with perfect HTML) - It's related to how I've built the page (the Zope Welcome screen is fine, other pages built using the same product don't work. The product I'm building is a folderish thing with lots of extra navigational services) - it's always the last 11 bytes that are missing, however large the page is - I've sent exact copies of the HTTP headers to the server, using telnet, and there's no problem there I imagine the fact that I can make it work by adding index_html is the most telling point, but it's not telling me anything ;) I'll continue my research by eliminating elements until I've nailed down exactly the bit that's messing it up. Right now, though, I have to go to bed. Meanwhile, any comments? Cheers, seb
From: seb bacon <seb@jamkit.com>
I imagine the fact that I can make it work by adding index_html is the most telling point, but it's not telling me anything ;)
Leaving off index_html causes Zope to add a <base href> to the head. That's the only difference I can think of. Your page doesn't get cut short in my IE 5.00.2314.1003 (128 bit encryption). Cheers, Evan @ digicool & 4-am
On Thu, 14 Dec 2000, Evan Simpson wrote:
From: seb bacon <seb@jamkit.com>
I imagine the fact that I can make it work by adding index_html is the most telling point, but it's not telling me anything ;)
Leaving off index_html causes Zope to add a <base href> to the head. That's
WHOW ! <base href> is exactly 11 bytes long. Couldn't it be that the content-length is computed by Zope before you automatically add this tag ? just my 0.000002 euros Jerome Alet
On Fri, Dec 15, 2000 at 08:48:18AM +0100, Jerome Alet wrote:
On Thu, 14 Dec 2000, Evan Simpson wrote:
From: seb bacon <seb@jamkit.com>
I imagine the fact that I can make it work by adding index_html is the most telling point, but it's not telling me anything ;)
Leaving off index_html causes Zope to add a <base href> to the head. That's
WHOW !
<base href> is exactly 11 bytes long. Couldn't it be that the content-length is computed by Zope before you automatically add this tag ?
This indeed *seems* to be the problem with this server, the content-length is 14 bytes (not 11) too short. This isn't a general Zope bug however, only a bug with this particular server. Zope adds \n<base href="http://test.jamkit.com/">\n, which is 39 bytes extra (including newlines): sneek:~> telnet test.jamkit.com 80 Trying 213.210.4.254... Connected to 213.210.4.254. Escape character is '^]'. GET / HTTP/1.0 Host: test.jamkit.com HTTP/1.0 200 OK Server: Zope/Zope 2.2.2 (source release, python 1.5.2, linux2) ZServer/1.1b1 Date: Fri, 15 Dec 2000 09:53:15 GMT Content-Type: text/html Content-Length: 4226 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <html><head></head> <head> <base href="http://test.jamkit.com/"> <title>WebFactory</title> [<SNIP rest of content>] Note the content lenght of 4226. Now compare with /index_html: sneek:~> telnet test.jamkit.com 80 Trying 213.210.4.254... Connected to 213.210.4.254. Escape character is '^]'. GET /index_html HTTP/1.0 Host: test.jamkit.com HTTP/1.0 200 OK Server: Zope/Zope 2.2.2 (source release, python 1.5.2, linux2) ZServer/1.1b1 Date: Fri, 15 Dec 2000 09:53:50 GMT Content-Type: text/html Content-Length: 4201 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <html><head></head> <head><title>WebFactory</title> <meta content="text/html; charset=iso-8859-1" http-equiv=content-type> [<SNIP rest of content>] Note again the content length, 4201. Now, 4226 - 4201 = 25. It seems we lost 14 bytes of content! However, I cannot reproduce this on my 2.2.4 server, or a Zope 2.2.2 source install, or on www.zope.org. All produce the correct number of bytes sent! Even better, if you don't send the host header to the test.jamkit.com server, you get www.cemcrem.com, which sends the correct lengths as well! All this points to something wrong with the particular server itself. Either there is a proxy in between that recalculates the content length (and forgets about \r\n conbos or some such thing), or you modified the Zope source somewhere, or you are doing something else funny. -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ ---------------------------------------------
Firstly, apologies for cross-posting - this should probably move over to zope-dev henceforth. Secondly, thanks for the replies. In my small sample, it appears that 3 out of 7 IE browsers got the bug - no other flavours had a problem at all. They were mostly versions 5 and 5.5. If there was any pattern, it's possible that 56-bit versions were the baddies, but that's not clear yet. As Martijn correctly pointed out, there seems to be a Content-length problem going on here. I did a lot more tests on two different 2.2 servers, and have come closer to isolating the bug. Contrary to what I said, it *is* triggered by bad html: the </head> tag was missing. In documents of a certain length (at least 2000 bytes), which contain the <base href> tag, but don't have a </head> tag, the Content-length is consistently reported as 14 bytes too short. This is regardless of the actual length of the document. Why this should have a knockon effect on a small subset of MS browsers, I don't know. Especially confusingly random is the requirement for a certain amount of data to break these browsers. Even more mysteriously, if I replicate the data which zope is sending to the browser using netcat (bad content-length, same content), IE doesn't complain. Things like Keep-alive perhaps spring to mind? Anyway, I have fixed the problem in terms of my users by adding the </head> tag, but this looks suspiciously like a ZServer problem as well as an IE rendering problem. I'm off on holiday tomorrow evening and I don't have any more time to investigate. I haven't checked against other versions of Zope, but the one I'm using is only patched in DT_Util.py. This is such a dumb problem it's just *got* to be my fault somewhere down the line :) I'll check against other servers when I get back (mid Jan - long holiday :-) cheers, seb
From: seb bacon <seb@jamkit.com>
As Martijn correctly pointed out, there seems to be a Content-length problem going on here. I did a lot more tests on two different 2.2 servers, and have come closer to isolating the bug.
It's a ZPublisher/HTTPResponse.py bug. When you render a Folder, it inserts the <base href=...> and adjusts the content-length. When the RESPONSE is rendered, it notices that the </head> is missing and tries to fix your HTML (adding precisely 14 bytes), but doesn't bother to re-adjust the content-length. I've fixed this in CVS by removing the code that attempts to fix HTML, since that is *wrong* behavior. You can do the same by removing the following lines: else: isHTML = split(headers.get('content-type', ''), ';')[0] == 'text/html' if isHTML and end_of_header_search(self.body) < 0: lhtml=html_search(body) if lhtml >= 0: lhtml=lhtml+6 body='%s<head></head>\n%s' % (body[:lhtml],body[lhtml:]) elif contHTML: body='<html><head></head>\n' + body else: body='<html><head></head>\n' + body + '\n</html>\n' self.setBody(body) body=self.body Cheers, Evan @ digicool & 4-am
participants (4)
-
Evan Simpson -
Jerome Alet -
Martijn Pieters -
seb bacon