2.3.0 release badness
I've just updated to 2.3.0 release using CVS. My CSS serving has subsequently broken. The CSS serving worked fine with the CVS code from 2.3.0b2. I didn't get to check b3 - we had a public holiday on Friday and that meant that the one working day assigned to the b3 release was lost to me (and _most_ other Australians). Anyway, that's a separate issue ... I've done a diff against the CVS as of last Tuesday, but I can't see an obvious place where the Zope code has changed to make the CSS serving fail. Under Netscape (versions 4.72 -> 4.75), a 'back button' request results in a truncated plain-text display of the CSS that is linked from the page. The zope server log shows the request as being successfully served. I telnet'ed to the server and requested the CSS manually, and the headers all look fine. A packet sniffer seems to say that all is well. Now for the fun: this only happens for local requests - someone requesting the same pages over the ethernet will get them fine. Only Netscape and only locally. Konqueror locally works fine. The CSS is being served using the attached class. Some further experimentation: 1. load the same page five times as follows: http://mymachine:8080/blah/ http://127.0.0.1:8080/blah/ http://127.0.0.2:8080/blah/ http://10.0.0.20:8080/blah/ http://127.0.0.3:8080/blah/ 2. starting from either end of those URLs in the browser history, hit the 'forward' button or 'back' button four times to get to the other end. 3. note that the first hit of 'forward' or 'back' (and sometimes other hits too) the CSS is served as plain text Of course, embedding the style in the page (a-la the Zope management interface) gets around this problem, but this is not an option for us. Again, this was not a problem pre 2.3.0 b3 / release... Richard -- Richard Jones richard@bizarsoftware.com.au Senior Software Developer, Bizar Software (www.bizarsoftware.com.au)
richard@bizarsoftware.com.au wrote:
I've just updated to 2.3.0 release using CVS. My CSS serving has subsequently broken. The CSS serving worked fine with the CVS code from 2.3.0b2. I didn't get to check b3 - we had a public holiday on Friday and that meant that the one working day assigned to the b3 release was lost to me (and _most_ other Australians). Anyway, that's a separate issue ... (...) Under Netscape (versions 4.72 -> 4.75), a 'back button' request results in a truncated plain-text display of the CSS that is linked from the page. The zope server log shows the request as being successfully served. I telnet'ed to the server and requested the CSS manually, and the headers all look fine. A packet sniffer seems to say that all is well. (...) Now for the fun: this only happens for local requests - someone requesting the same pages over the ethernet will get them fine. Only Netscape and only locally. Konqueror locally works fine. (...) Again, this was not a problem pre 2.3.0 b3 / release...
Richard
Hi! Nope, this is not only a problem of 2.3.0. I have had the same issue in all of the 2.3.0x Zope versions, and the problem is not really Zope but Netscape 4.X. For me, the trouble arises once in a while and specially when I start doing page reloads quickly. It seems that, when Zope starts serving the document, Netscape asks for the stylesheet file almost instantly (because it is inside the HTML's header) and then a sort of synchronizing error happens. When you are at the local machine the delay between the document requests is larger so the problem is less frequent. I have never seen the problem under Netscape 6 or Mozilla. I don't know to what extent this could be Zope's fault. Cheers! -- Pablo Bleyer Kocik | pbleyer |"Rintrah roars & shakes his fires in the burdend air; @embedded.cl | Hungry clouds swag on the deep" William Blake
the HTML's header) and then a sort of synchronizing error happens. When you are at the local machine the delay between the document requests is larger so the
^^^^ Oops. That should be "When you are *not* at the local machine...". Sorry ;^) -- Pablo Bleyer Kocik | pbleyer |"Rintrah roars & shakes his fires in the burdend air; @embedded.cl | Hungry clouds swag on the deep" William Blake
Pablo Bleyer Kocik wrote:
Nope, this is not only a problem of 2.3.0. I have had the same issue in all of the 2.3.0x Zope versions, and the problem is not really Zope but Netscape 4.X.
For me, the trouble arises once in a while and specially when I start doing page reloads quickly. It seems that, when Zope starts serving the document, Netscape asks for the stylesheet file almost instantly (because it is inside the HTML's header) and then a sort of synchronizing error happens. When you are at the local machine the delay between the document requests is larger so the problem is less frequent.
I have never seen the problem under Netscape 6 or Mozilla. I don't know to what extent this could be Zope's fault.
Thanks for this excellent responses. We'll now be writing something that parses and replaces the CSS <link> with the CSS source for the Mozilla/4 clients. Richard ps. sorry for besmirching the good name of 2.3.0 :) pps. my original comment about the extremely short b3 release still stands though... -- Richard Jones richard@bizarsoftware.com.au Senior Software Developer, Bizar Software (www.bizarsoftware.com.au)
richard@bizarsoftware.com.au wrote:
Of course, embedding the style in the page (a-la the Zope management interface) gets around this problem, but this is not an option for us.
This is a known bug in Netscape. The management interface does user-agent sniffing; "Mozilla/4*" that doesn't contain the string "MSIE" embeds the style while all other user-agent strings link the CSS instead. You'll notice that if you "view source" on MSIE, the CSS is linked rather than embedded. Perhaps you can use the same strategy. It's done in DTML. Shane
Shane Hathaway wrote:
richard@bizarsoftware.com.au wrote:
Of course, embedding the style in the page (a-la the Zope management interface) gets around this problem, but this is not an option for us.
This is a known bug in Netscape.
I'm intrigued to know what causes it (in more detail than "race condition"). Do you have a URL for a description of the bug? Thanks. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
Steve Alexander wrote:
Shane Hathaway wrote:
richard@bizarsoftware.com.au wrote:
Of course, embedding the style in the page (a-la the Zope management interface) gets around this problem, but this is not an option for us.
This is a known bug in Netscape.
I'm intrigued to know what causes it (in more detail than "race condition"). Do you have a URL for a description of the bug?
It seems to occur on Unix versions only AFAIK. When you visit a page with linked CSS, visit another page, and come back, sometimes a portion of the page is replaced with the text of the CSS. I don't have a URL. Shane
Shane Hathaway wrote:
It seems to occur on Unix versions only AFAIK. When you visit a page with linked CSS, visit another page, and come back, sometimes a portion of the page is replaced with the text of the CSS. I don't have a URL.
i've had a nice variant of this in Windoze Nutscrape. Sometimes, it'll just sit there redirecting back to the css page infinitely.. yum :-S Chris
Chris Withers wrote: [snip]
Sometimes, it'll just sit there redirecting back to the css page infinitely.. yum :-S
Yeah, I've seen that kind of weirdness show up too occasionally; some kind of infinite css getting loop in Netscape. A couple of times I've seen it blow up the server logs; I suspect a netscape left open to our site in a computer lab somewhere. Is really good for inflation of your server statistics. :) But-Mozilla-flakes-out-on-the-back-button-so-which-do-I-pick-ly yours (*) Martijn (*) comp.lang.python Tim Peters style signoff (modified)
FWIW, I recall having similar problems with external JavaScript files in NS - it seemed that the onload event of the body is triggered *before* the external JS is loaded into the namespace.
-----Original Message----- From: zope-dev-admin@zope.org [mailto:zope-dev-admin@zope.org]On Behalf Of Steve Alexander Sent: 29 January 2001 17:07 To: Shane Hathaway Cc: zope-dev@zope.org Subject: Re: [Zope-dev] 2.3.0 release badness
Shane Hathaway wrote:
richard@bizarsoftware.com.au wrote:
Of course, embedding the style in the page (a-la the Zope management interface) gets around this problem, but this is not an option for us.
This is a known bug in Netscape.
I'm intrigued to know what causes it (in more detail than "race condition"). Do you have a URL for a description of the bug?
richard@bizarsoftware.com.au wrote:
I've just updated to 2.3.0 release using CVS. My CSS serving has subsequently broken. The CSS serving worked fine with the CVS code from 2.3.0b2. I didn't get to check b3 - we had a public holiday on Friday and that meant that the one working day assigned to the b3 release was lost to me (and _most_ other Australians). Anyway, that's a separate issue ...
I've done a diff against the CVS as of last Tuesday, but I can't see an obvious place where the Zope code has changed to make the CSS serving fail.
Under Netscape (versions 4.72 -> 4.75), a 'back button' request results in a truncated plain-text display of the CSS that is linked from the page. The zope server log shows the request as being successfully served. I telnet'ed to the server and requested the CSS manually, and the headers all look fine. A packet sniffer seems to say that all is well.
Now for the fun: this only happens for local requests - someone requesting the same pages over the ethernet will get them fine. Only Netscape and only locally. Konqueror locally works fine.
I can confirm this type of bug with Netscape. For more fun; if you're serving Zope behind Apache (at least using PCGI) the bug does not occur. I've seen this for far older versions of Zope too; I've run into this type of netscape/ZServer weirdness in earlier 2.2.x versions at least. So I suspect this is not a new bug. Not sure if it's Zope or Netscape that's doing something wrong, either.
Again, this was not a problem pre 2.3.0 b3 / release...
Again, I think it was -- I've seen it before. Regards, Martijn
participants (7)
-
Chris Withers -
Martijn Faassen -
Pablo Bleyer Kocik -
richard＠bizarsoftware.com.au -
Seb Bacon -
Shane Hathaway -
Steve Alexander