Closed Bug 100514 Opened 23 years ago Closed 23 years ago

Mozilla refresh of a Tomcat generated webpage sometimes doesnt work

Categories

(Core :: Networking: HTTP, defect, P2)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
mozilla0.9.9

People

(Reporter: jbaker, Assigned: darin.moz)

References

(
URL
)

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913 BuildID: 2001091311 (Milestone 0.9.4) For some reason, since Milestone 0.9.2, Mozilla doesn't refresh a page generated by the Tomcat 4.0 jsp/servlet engine. The page is displayed, and when refresh is pressed it writes: <html><body></body></html> to the browser. No request is made and nothing appears in the Tomcat access logs when this situation occurs. It's very annoying as this never happens with 0.9.2. I'm going to try and produce a page (test.jsp, in url above) that will demonstrate this but it's fairly random. Maybe it's some of the caching meta tags in the html produced? Reproducible: Sometimes Steps to Reproduce: 1.Go to that url 2.Press refresh repeatedly 3.It might cause the problem... I've posted a mail to the Tomcat mailing list and others have tried and got the same odd behaviour. It's only ever a tomcat generated webpage, so I think it might have something to do with the headers returned. I've seen the bug on my Linux box, and on the Windows Mozilla binaries. I'm happy to help debug it or run some test code etc if need be. This bug prevents me developing Tomcat webpages using Mozilla 0.9.3+. I have to have two copies installed :-) I've tried various nightly builds and hoped 0.9.4 might resolve the issue, and as it hasn't, I'm now reporting it :-)
Ah ha, I dont mean meta tags caching, I mean in the HTTP response:GET /test.jsp HTTP/1.0HTTP/1.1 200 OKContent-Type: text/html;charset=ISO-8859-1Date: Wed, 19 Sep 2001 11:08:33 GMTPragma: no-cacheServer: Apache Tomcat/4.0-rc1 (HTTP/1.1 Connector)Cache-Control: no-cacheConnection: closeExpires: Thu, 01 Jan 1970 00:00:00 GMTSet-Cookie: JSESSIONID=42F7892547926733E331A2953673D5D3;Path=/
i don't think xp apps is the right place for this. networking? [wild guess]
Assignee: pchen → neeti
Component: XP Apps → Networking
QA Contact: sairuh → benc
Err, yes. This is my first attempt at a bug. I suspect I missed "XP apps", not that I know what that is ;-) Now I tried test.jsp and added a link to test2.jsp. I went back and forward and it seemed to work. I left it fora few mins, came back, pressed back and the bug showed itself. So I still can't figure out exactly how to reproduce it, but I'm now sure it's possible with the two test jsp pages I put online (like, almost empty jsp pages :-).
-> http John: it's okay. Networking gets a lot of XP apps bugs, so they "owe" us :) Moving to HTTP, (athough I created a similar bug last night about an IBM site, and sent it to browser-general...)
Component: Networking → Networking: HTTP
I can't duplicate this on the provided test pages, but I have seen this behavior before when working with Tomcat. I believe it happens every time right after you change a jsp file and Tomcat has to recompile it, so I suspect this may be Tomcat sending out bad headers when it is busy compiling a page.
Right. I've done some more testing. Tomcat recompiling web pages can cause this but in most situations, when no jsp is being recompiled (as on my test site), *MOZILLA MAKES NO REQUEST TO TOMCAT*. That's right. The access log contains NO REQUEST. I just wanted to make that point clear :-) Try this, go to the link I provided. Wait five minutes. Click the link. I tried this a few times and it did break for a few goes. Mozilla *does not work with Tomcat web servers* at present. It *used to work* and if I get a Mozilla 0.9.2 binary, the problems go away. For good. Lots of people are going to start using Tomcat 4.0+ soon, I wouldn't want Mozilla to be a banned browser due to the fact it just doesn't work. I'm trying to push Mozilla within our company and within Schlumberger. We build services using Tomcat and I can't do a demo with it because it's just too unreliable with this problem. Help :)
Networking, apparently. Wait 1 min so that the server closes the socket, then click the link. Tcpdump shows that Mozilla 0.9.5/Linux opens a second socket, but is confused and closes it immediately after the SYN reply from the server, before the server sends data, and displays <html><body></body></html>. Mozilla 0.9.5/Win is even worse: It doesn't even attempt to open a second socket, only completes the FIN handshake for the first socket when the link is clicked. IE 4.0/Win works fine: When the server sends FIN for the first socket, it completes the closing handshake immediately. When the link is clicked it opens a new socket and does the transaction.
Yah! I'm not wrong! This is a real bug. Thanks RB for that informative follow up. Feer those tcpdump skills ;-)Now can someone please sort it? :-)
Assignee: neeti → darin
QA Contact: benc → tever
-> darin
-> major, at most, too.
Severity: blocker → major
-> 0.9.7
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P2
Target Milestone: --- → mozilla0.9.8
reporter: can you verify that this problem still exists with a recent mozilla nightly build? thx!
Ok, I will after Christmas. So Jan 10th or so and I'll let you know.John
pushing out to 0.9.9
Target Milestone: mozilla0.9.8 → mozilla0.9.9
What?? You're altering the release milestone jsut because I dont have time to test it? Cant someone download Tomcat from http://jakarta.apachae.org, run it, and test it?
i'm pushing out the milestone because i don't have time this milestone (what with the impending holidays) to setup a tomcat server and test this.
Recent builds (2001121921/Linux) behave differently than 0.9.5, as tcpdump shows, but since the full page http://expert.teamenergy.com/index.jsp (unlike the test case) does not show the bug in 0.9.5, I cannot say if the bug is gone. When the server after a 1 min idle connection sends the FIN packet on the original socket(s), Mozilla 2001121921 replies with an ACK, but eventually closes the socket(s) after a delay of up to 20 sec. One can assume that there will be no problems with "reload" after the original sockets are closed, but it is not possible to say what will happen in the (short) time window between the arrival of the FIN packet from the server and the FIN reply from Mozilla. (Why Mozilla keeps a half-closed socket for some time is beyond me, but my TCP/IP is not that good either ...)
I develop with Tomcat virtually all day every day. After Christmas I will no doubt doing the same. I haven't seen the problem in some time but I have just downloaded 0.9.7 and will test this to see if I can get the problem to reoccur. I will make another posting within a few weeks to let you know what my results are. I say a couple of weeks, but I hope it will be sooner :-)
Ok, with 0.9.7 I dont seem to have this problem anymore. I'll therefore declare this, in my opinion, fixed. I'll let you know if it reappears. However it is good to be able to use Mozilla and Tomcat now without embarassing "Oh it always does that" sentences when the problem occurred ;-)
something like this now reported in bug 118760
Reference bug 118760, I am having problems with Mozilla refusing to load and apply the stylesheet (even though the pages validate perfectly) but I assumed this night be a more widely known problem.
bug 118760 has nothing to do with tomcat... the reporter was feeling the side effects of bug 76431 :-( jbaker: i'm closing this bug out as WORKSFORME... please reopen if you notice this problem again.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Verified WFM.
Status: RESOLVED → VERIFIED
QA Contact: tever → junruh
You need to log in before you can comment on or make changes to this bug.