Closed Bug 231072 Opened 21 years ago Closed 20 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: 20 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: