Closed Bug 141179 Opened 22 years ago Closed 22 years ago

Page does not load with pipelining enabled

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED DUPLICATE of bug 162448
Milestone:
Future

People

(Reporter: mozbug, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: topembed, Whiteboard: [pipelining]) 

2002042822 trunk linux
20020428xx trunk win 98

Disable HTTP/1.1 pipelining
Load url.
Page loads fine.
Enable HTTP/1.1 pipelining.
Clear cache.
Load url.
Parts of page is loaded and never finishes to load.
Whiteboard: [pipelining]
it appears that the server at www.fortisbanking.de does not support pipelining.
 the server is Microsoft-IIS/4.0, and it only responds to the first request in a
pipelined request.  i'm not sure if this is a problem with IIS/4.0 per se or a
problem with some server side CGI or what-have-you.  we could get around this
problem by not pipelining to IIS/4.0, but that might be like taking a sledge
hammer to a tooth-pick ;-)
Also with apache and pipeling support configurations there are problems.
Have a table with picture and only some of them are loaded. switching of
piplingin everything gets normal.
Blocks: 144326
mass futuring of untargeted bugs
Target Milestone: --- → Future
*** Bug 145477 has been marked as a duplicate of this bug. ***
*** Bug 145404 has been marked as a duplicate of this bug. ***
*** Bug 144326 has been marked as a duplicate of this bug. ***
With the amount of dupes (different sites) and the effect I've seen on multiple
sites including Apache and IIS I'm going to to whine just a bit, and bitch a lot
that this has been futured.

The effect to users is astounding and I've also seen http responses displayed
which can represent a security issue. 

Imagine if your online banking didn't work with Mozilla 1.0. Which browser would
you use?

Here is another example:

https://qualysguard.qualys.com/fo/user_login.php

Note that the lower frame will evetually display the server response.

If http 1.1 pipelining is to be futured, it should be removed from the prefs
altogether for 1.0

Darin, any progress on this?

-jim
(ex: race@netscape.com)
No longer blocks: 144326
I'd have to agree that if this is not fixed before 1.0, then the pref to enable
pipelining should be removed.  As it stands, I dont think that pipelining should
be on by default, not sure whether it is or not?
It is not enabled by default, but if it is enabled the results can be a Bad
Thing (tm). 

Don't get me wrong. When it works, browsing speed is way faster.
(way=nominal*42/42) but when it fails it is seriously fugly.

Joking above. Pipelining is *WAY* faster, when it works.
agreed... there are many misbehaving websites out there.  there's no hope of
adding workarounds to mozilla in time for 1.0, but there will be a release note
warning users of the potential problems associated with pipelining.

keep in mind, the pref has provided us with some very useful data.  without it,
i don't think we would have nearly this number of bug reports despite the
existance of real problems.

of course, a polished product should not have any flaws, but then again... i can
site numerous examples in which our default networking prefs (HTTP/1.1 with
keep-alive enabled) cause websites to fail or load badly, and the situation is
much worse when you consider the various bad (only understands HTTP/1.0
requests) proxy servers out there (junkbuster and MS proxy come to mind).

so, i think leaving the pref is reasonable provided there is some means for the
user to learn that that pref may be the reason why some site is not loading
correctly.  a relnote isn't the best way to do this, but at least it is
something :-/
I think we can add <http://www.kanal5.se/> to the list of sites that don't agree
with pipelining; the home page will not load at all. The site runs IIS 5.0,
which is an interesting twist.

Tested in build 20020521-10, 1.0.0-branch, on Linux.
List of hosts not working can now also include www.citizensbankonline.com which
is running IIS 4.0...
I can verify Daniel's report about Citizens Bank Online. To clarify, the URL is
<https://www.citizensbankonline.com/>.

Tested in RC3, build 20020523-16, on Linux.
With pipelining on, I've indeed seen the raw server response show up in
framesets, like comment 8 says.  So far it always seems to be PHP-related. 
Sites running the somewhat cheesy "websiteOS" software
(http://www.hostopia.com/websiteos.phtml) exhibit this often.

I either see the server response raw, or Mozilla asks me how I would like to
save this PHP mimetype.  

If all pipelining bugs have been futured, the preference item should contain a
warning...
Here is another problem site: <http://www.arbetarbladet.se/>. When I try to
enter, I get a download dialog.

The server identifies itself as: "Apache/1.3.20 (Unix) (Red-Hat/Linux)
PHP/4.0.4pl1", which is in line with comment #15.

Using RC3, build 20020523-16 on Linux.


trunk builds no longer pipeline to IIS/4.0 (i'm hoping to land this fix on the
1.0 branch sometime after 1.0 ships).  i'm working on a patch to add a warning
comment to the HTTP Networking prefs panel (there's already a relnote warning).

pipelining bugs are futured, not because i want to ignore them, but because i
want to selectively pull-in only those bugs that i know i will have time to fix
by the next milestone.
www.oracle.com is another site that for me doesn't appear to enjoy pipelining
switched on!

goto www.oracle.com
click database on the left hand side.  Page rarely loads (dialup / w2k/
2002052206 + others)

Turn pipelining off. Works fine.
*** Bug 147952 has been marked as a duplicate of this bug. ***
http://www.authorize.net breaks with pipelining on, in a strange way.  The front
page loads fine, but the subsequent pages delay about 45 seconds before
appearing as one, gigantic, broken GIF, along with the words "The image [page
url] cannot be displayed, because it conatins errors", where [page url] is the
location of the page I'm attempting to load.  The real page is _not_ one big image.

Can be recreated by hitting any item on authorize.net's front toolbar with
pipelining on.  

Should I stop filling this bug with reports of that don't load?  I considered
this one worth talking about because it's on the latest builds (2002052803 and
2002053011), and the site isn't IIS/4.0 (it seems to be 5.0). 
with linux build 2002-06-17/21:

https://www.fortisbanking.be/                        ==> works!
https://qualysguard.qualys.com/fo/user_login.php     ==> works!
http://www.kanal5.se/                                ==> FAILS!
https://www.citizensbankonline.com/                  ==> works!
http://www.hostopia.com/websiteos.phtml              ==> works!
http://www.arbetarbladet.se/                         ==> works!
http://www.authorize.net                             ==> uncertain

so for the most part, i'd say this bug is WFM.  perhaps the bug can shift to
target the links that are still misbehaving.
Here is another site that still doesn't work: <http://www.aeg.se/>. The site
runs Microsoft-IIS/5.0.

Tested in: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020625.
Here is another Microsoft-IIS/5.0 site that doesn't work properly:
<http://www.motalatidning.se/> - the images won't load.

Re comment #20: For me the problem is immediately apparent: the images on the
front page won't load. ( http://www.authorize.net/ )

Tested in: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020625.
Blocks: 144480
No longer blocks: 144480
https://qualysguard.qualys.com/fo/user_login.php,
https://www.citizensbankonline.com/, http://www.hostopia.com/websiteos.phtml all
work. And all the images on http://www.motalatidning.se/ load. Pipelining is
enabled for HTTP 1.0 and 1.1. Why am I not seeing these problems?
Re comment #24: I find that sites you mention work for me too, with the
exception of http://www.motalatidning.se/, which after a number of completete
reloads (while pressing SHIFT) will not load any images or stall completely.

BTW, here is another potential problem site, running Microsoft-IIS/5.0:
http://www.electrolux-wascator.com/

Tested in: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020627.
I beleive this has been fixed by the checkin for Bug #162448. 

Marking fixed. If you disagree, please reopen with example URL's.

*** This bug has been marked as a duplicate of 162448 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed
verified duplicate
Status: RESOLVED → VERIFIED
Blocks: grouper
You need to log in before you can comment on or make changes to this bug.