Closed Bug 231072 Opened 21 years ago Closed 21 years ago

mozilla now unable to load stories at tv2.no/nettavisen

Categories

(Tech Evangelism Graveyard :: Norwegian, defect)

Product:
Tech Evangelism Graveyard
Component:
Norwegian
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: spam, Unassigned)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(1 file)

screenshot
117.50 KB, image/jpeg
Details
Testsed on Linux. Happened between 2004-01-07-09-trunk and 2004-01-08-09-trunk: -The first build is fine and loads the page in a second or two. -The later build still hasn't loaded a story after 5 minutes. The URL in URL location of the bug is just a sample - the bug can be observed with any story-link at the site. I believe these are the checkins made in the relevant timespan: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=01%2F07%2F2004+07%3A00&maxdate=01%2F08%2F2004+09%3A00&cvsroot=%2Fcvsroot Setting severity blocker. This regression completely breaks the second most popular newssite in Norway.
Site works on WinXP with the release of Mozilla 1.6, just a little slow.
Summary: Regresseion: mozilla now unable to load stories at tv2.no/nettavisen → Regression: mozilla now unable to load stories at tv2.no/nettavisen
confirming it takes forever loading this page (I'm connected to a fast corporate line), using FB 20030114 Trunk on Win2k. IE6 on same computer loads and renders page fine in less than 1 second.
OS: Linux → All
Same here, 1.6 NetBSD-1.6.1 x86 - Similarly I get a complete hang trying to go to http://www.kakaku.com/ Just me? Lund
http://www.kakaku.com/ is unrelated. Perhaps a local fontserver issue? Loads fine here, current CVS. Notice that when tv2.no/nettavisen stories don't load, mozilla just keeps spinning the throbber while CPU usage is low/unnoticable.
Ethereal shows the HTTP header Content-Location defined with URI http://pub.tv2.no:3002/nettavisen/veden/irak/article.jsp When loading this URI manually, it fails (connection failed). I'm pointing this as the behaviour with Content-Location changed recently (biesi enhanced this). This header doesn't show up on http://pub.tv2.no/nettavisen/ and it loads very fine on same build as in comment 2
Aha. Backing out the changes to nsContentSink.cpp did the trick. Adding comment in bug 109553.
Assignee: general → parser
Severity: blocker → major
Status: UNCONFIRMED → NEW
Component: Browser-General → HTML: Parser
Ever confirmed: true
actually, it was bz who made the content-location patch, not me that said, isn't it entirely the site's fault if it sends an invalid content-location header?
Also happens on Mac OS X (both latest Mozilla-trunk and Camino).
Hardware: PC → All
Yeah. It's just like as if it sent a bogus <base> and we suddenly added <base> support. Evang.
Assignee: parser → norwegian
Component: HTML: Parser → Norwegian
Product: Browser → Tech Evangelism
QA Contact: general → norwegian
Hardware: All → PC
Version: Trunk → unspecified
There is no other browser that is unable to deal with that site. And mozilla has been capable of it for many years, untill the past few days. If this is evang, I'll delete Mozilla and install Opera instead.
We had content-base support and it was dropped because of: - it was deprecated some time ago - there were sites sending a bogus content-base header that failed to load Now we seem to have the same thing with content-location, except it is not deprectated. What does the sent content-location header look like in this case? If it is relative we have a problem, because as far as I know, it is allowed but we do not handle that. If not, it most probably is a bogus header, and it is an evang problem. The site must fix it.
Okay, found it in comment #5. It's absolute. The reason other browsers do not fail with this url may be that they do not support the content-location header.
hmm.. According to bug 109553 comment 10, Opera should have the same exact problem on this site, no? Ian? Andreas, we _do_ handle relative content-location; see patch in bug 109553.
QA Contact: norwegian → ian
Just to clarify what's going on, rkaa, we added support for an HTTP header that this site uses that we didn't use to support. Unfortunately, this site _mis_uses it. Which is a problem. IE has no support for this header, so IE is not affected (like older Mozilla's). Opera, according to Ian, supports this header.
well Mozilla doesn't pass this one at least - Opera passes. http://jigsaw.w3.org/HTTP/CL/
That's the test I used to test my content-location impl. Mozilla with my patch passes it... So Opera passes that test but does _not_ fail with the pub.tv2.no site? Ian, what the hell is going on with that browser?
oops - my bad! i tested an old mozilla build. Forget that test.
trying to sniff this through a firewall and new NAT router, but failing so far.. As far as I understand it, however, multiple Content-Location headers should be allowed - is that the case here?
Multiple Content-Location headers are allowed by the Mozilla code. It's not clear what the right thing to do is per the HTTP specs. In this case there is only one content-location header. One interesting thing here is that the only resources using relative URLs are stylesheets. Does Opera display the site with the right stylesheets? It may be that in Opera pending stylesheet loads do not prevent layout. See bug 84582. If this is what's going on, it may be simplest to back out bug 109553 and reland once bug 84582 is fixed (though this site would still not get its stylesheets).
It actually does load - eventually. Takes closer to 18 minutes though, so it's too slow to be of any practical use.
BTW: Amaya v. 7.2 also loads the URL instantly. like Opera. http://pub.tv2.no/nettavisen/innenriks/article173957.ece
Right. But do Amaya and Opera apply those stylesheets? That's what I was really asking in comment 19.
not sure which stylesheets are applied, but Opera and Amaya do style the page a lot more than mozilla is able to today. Build from the 7th looked approx like opera today. Attaching screenshot of all three - todays mozilla - opera - amaya
Attached image screenshot —
> If this is evang, I'll delete Mozilla and install Opera instead. Opera has a bug whereby it ignores Content-Location if it points to a different host or port (i.e. it only takes into account the path part of Content-Locations). I'll try to get this fixed in Opera.
(o135038)
OK. So even if I fix the hang (bug 84582), the site still won't be styled... Ian, what're your thoughts? Could Opera possibly apply pressure to this site to fix (as a local company, it may have more weight than Mozilla would)?
Does Amaya have the same bug as Opera then? Isn't Amaya the W3C-made browser?
It is, yes. I tried to look through the Amaya code looking for how they handle content-location, and it's even less readable than Mozilla code... so I gave up.
Amaya is not meant to be a usable browser as I understand it; it's a test-bed browser for prototyping new ideas for specs. As such it is probably one of the least-compliant UAs on the "market". It wouldn't at all surprise me if it didn't support Content-Location well. How does it do with my testcases?: http://www.hixie.ch/tests/adhoc/http/content-location/001.html http://www.hixie.ch/tests/adhoc/http/content-location/002.html http://www.hixie.ch/tests/adhoc/http/content-location/003.html http://www.hixie.ch/tests/adhoc/http/content-location/004.html http://www.hixie.ch/tests/adhoc/http/content-location/005.html
bz: I'd contact them, but, uh, I can't find their contact info. Anyone see what e-mail address I should contact for this site?
Driftsansvarlig IT: Roy Toresen roy.toresen@tv2.no Telefon (direkte innvalg): 21 00 61 61 There's also a valid webmaster@nettavisen.no address As for Amaya: It passes test 1,3 and 4 On test 2 it showed a red patterened square instead And on test 5 it seemed to hang. I hit return in urlbar twice, then backbutton, and then it crashed :)
> There's also a valid webmaster@nettavisen.no address Ok, thanks. > As for Amaya Like I said...
Using http://web-sniffer.net/ I don't see the content-location HTTP header anymore, Fixed ?
Not quite, the old problem page referred to above works fine now: http://pub.tv2.no/nettavisen/innenriks/article173957.ece but there are still other pages where the problem persists like for instance: http://pub.tv2.no/nettavisen/spray/slideshow/article195382.ece
Keywords: regression
Summary: Regression: mozilla now unable to load stories at tv2.no/nettavisen → mozilla now unable to load stories at tv2.no/nettavisen
seems all the links here suffer: http://pub.tv2.no/nettavisen/spray/spillsonen/ The page titles loads quick, but the rest of the pages takes over 10 minutes.
The fix for bug 238654 fixed this. Thank You, bz! Will be in 1.7. Resolving as WFM.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: