162448 - Page takes loooong to load with pipelining enabled [IIS/5.0]

Status: VERIFIED FIXED

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

Description

[Thierry Zoller]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1b) Gecko/20020804
BuildID:    2002080419

Go to the site.


Reproducible: Always
Steps to Reproduce:
Go to the site.
Wait.


Actual Results:  Site doesn't load correctly.

IE loads the page within 5 seconds.

Comment 1

[Jo Hermans]

Worksforme with build 2002072104 on NT.

It loads in 6.2 seconds. What do you mean with 'site doesn't load correctly'?

Comment 2

[Adrian Ulrich]

> IE loads the page within 5 seconds.

..from the cache?

Lynx can't load the page, dillo can't load the page..

looks like the server is down / has problems..
(Its IIS ;) )

Could you try it tomorrow again and give us a feedback?

thanks

Comment 3

[Nicu Buculei]

Confirmed. It seems that is a problem with the page: in IE loads ok, in Opera
got an error message, in Netscape 4.7 also an error about javascript in status bar:
JavaScript Error:
http://www.electrolux.de/files/includes/js/general.js, line
67:

document.getElementById is not a function. 
JavaScript Error:
http://www.electrolux.de/files/includes/js/general.js, line
67:

document.getElementById is not a function.
The site is broken, I supose is a Tech Evangelism issue

Comment 4

[wacheo]

confirmed on linux build 2002080902.

looks like a pipelining problem. When I disabled pipelining it works fine.

nicu: NS4.7 doesn't support getElementById and that's why you see the error.
getElementById is a standard compliant function.

Comment 5

[Darin Fisher]

looks like we have to add IIS/5.0 to our pipelining blacklist.  this is not the
only report of it having trouble handling pipelined requests.

Comment 6

[Darin Fisher]

Attachment: v1 patch

add IIS/5.x to the pipelining blacklist.

Comment 7

[Gagan]

Comment on attachment 95118 [details] [diff] [review]
v1 patch

r=gagan

Comment 8

[jch]

I believe this is a problem with how Mozilla does pipelining.  The blacklist
approach is IMHO wrong.

While a server that claims to support HTTP/1.1 MUST support pipelining,
many don't. Thus, a UA that wants to pipeline requests should carefully probe
for server-side support.  The problem is that some servers discard their input
buffers between requests.

The approach that I've taken in a proxy I'm working on (not available ATM) is to
keep a cache of servers with information on their capabilities.  Initially, I do
no pipelining on a server.  When I've queued two requests for a server, I 
pipeline them both in what is hopefully a single IP packet, set a short (15 s)
timeout on that connection, and wait for replies.  If both requests succeed,
the server is noted as being able to do pipelining, and I then pipeline to my
heart's content.  If not, it becomes blacklisted.

I have never yet seen a server on which this heuristic fails to provide correct
results.  The only problems are that:

1. we do not do pipelining initially, but only after the server has been busy
enough to cause two requests to be queued; and

2. in cases when a server doesn't support pipelining, the users waits 10s for
the first two-element pipeline to fail.

Comment 9

[Darin Fisher]

jch:

yeah, i agree that ultimately it would be great if we could autodetect broken
HTTP/1.1 servers, but at the moment, it is a lot easier to blacklist servers
with known problems.  i understand that it is not always possible to determine
that a website will have this problem from the Server header alone since often
there are transparent proxies / virtual hosting systems causing the real
problem.  but, for the moment this is a reasonable simple solution.

not to mention the fact that 10s is not at all a reasonable delay for most
users.  if their first visit (after launching the browser) to a website always
results in a 10s delay then chances are they aren't going to enjoy using mozilla
to browse that site.  a blacklist takes care of a large percentage of the
problem cases.  IMO, it makes sense to add what you describe, but i'd still want
to keep the blacklist in place.

Comment 10

[jch]

> if their first visit (after launching the browser) to a website always
> results in a 10s delay then chances are they aren't going to enjoy using mozilla
> to browse that site.

If you think about it, the delay only happens between the first and the second
image on the page.  As you open two connections to the server (following the
recommendation in RFC 2616), and don't do any further pipelining on that server
while the probe is in progress, the other objects from that page get downloaded
immediately.

I agree with you, though, that it is reasonable to use both the blacklist
and probing.  What I object to is that no probing is done for unknown servers.

Anyway, it's on record now.

Comment 11

[Adrian Ulrich]

ok, ignore comment #2 .. the page _was_ down, but now i can see the (real) problem

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 95118 [details] [diff] [review]
v1 patch

sr=bzbarsky

Comment 13

[Darin Fisher]

fixed-on-trunk

Comment 14

[David G King]

If I'm right, this should also fix Bug #141179 and Bug #140561. Darin, can you
take a look, otherwise I'll try to take a look tonight when I've downloaded this
mornings nightly.

Comment 15

[David G King]

*** Bug 141179 has been marked as a duplicate of this bug. ***

Comment 16

[David G King]

OK, this also fixed Bug #141179, but it doesn't appear to have fixed Bug #140561.

Comment 17

[Tom Everingham]

verified - 10/01/02 trunk, win NT4, linux rh6, mac osX