some pipelined images aren't loading.

VERIFIED WORKSFORME

Status

()

Core
Networking: HTTP
VERIFIED WORKSFORME
16 years ago
9 years ago

People

(Reporter: Judson Valeski, Assigned: Darin Fisher)

Tracking

({topembed+})

Trunk
Future
x86
Windows 2000
topembed+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [pipelining], URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
win2k, trunk build from the 25th of April, 2002.

steps to reproduce:
1. visit said URL with http pipelining turned on (prefs->advanced->http
Networking. note: the URL can't be in your cache, so, do a shift reload once you
have pipelining on to hit the network fresh.
2. notice that the two images near the upper left headline summary area don't load.

If you turn pipelining off, they load. If you turn it back on and reload, they
won't.

Comment 1

16 years ago
same issue was reported in bug 140176 (see the first comment there)
(Reporter)

Comment 2

16 years ago
I'm not seeing the correlation between this bug and 140176. 

Comment 3

16 years ago
The similarity is that also in bug 140176, the images will load with pipelining
off, but do not load with pipelining on.
*** Bug 140777 has been marked as a duplicate of this bug. ***

Comment 5

16 years ago
Regarding if #140176 is a dup of this.

Has anyone got really really patient, and waited a long time to see if the
images will load given enough time?
(Assignee)

Comment 6

16 years ago
hmm.. under linux-smp, i'm unable to repro this problem using the 2002042707
build.  perhaps this website is triggering us to lose some race condition that
is more common on XP_WIN systems given the way win2k time slices?!  at any rate,
i'll give it a try on my win2k machine.
Also happening on stylesheets from time to time.
(Reporter)

Updated

16 years ago
Keywords: topembed
(Reporter)

Comment 8

16 years ago
data point. I can repro this using my other win2k machine, which is using a
different connection (speed/type); both are broadband though (dsl/t1).
(Assignee)

Comment 9

16 years ago
also seeing a related problem when viewing multiple performance graphs on
tegu.mozilla.org, e.g.:

http://tegu.mozilla.org/graph/multiquery.cgi?&testname=startup&tboxes=comet,luna,sleestack,mecca,facedown,openwound,rheeeet&days=7&autoscale=1&units=&ltype=&points=&avg=1
Status: NEW → ASSIGNED
Whiteboard: [pipelining]

Comment 10

16 years ago
Created attachment 81848 [details]
nsHttp:5 log for above url with and without pipelining

Maybe this will help in debugging.

The attachment is a zip containing two text files which are nsHttp:5 logs for
loading http://online.wsj.com/public/us. (Win2k 1.0-branch debug build from a
day back) One log is with pipelining and one without. 

At least one image did not load for me with pipelining turned on. Looking
through the source the filename for the image in question is:
col_it-ccartney0328.jpg

Hopefully, you can search through the logs to find out what happened to it.

For me, this is reproducible at will at the wsj site with my win2k 1.0 Branch
cvs debug build from a day or so back. At least one image from that page will
fail to load. I am on a pretty slow, high-latency connection. (BTW, I am not on
an SMP system.)

Comment 11

16 years ago
Oops ... cut-paste error in the image mentioned above above ... it should have 
been: col_it-mccartney03282002123027.jpg

Comment 12

16 years ago
That site WFM on WinXP build 2002050706

Comment 13

16 years ago
pipelining is desirable for embedding customers.
Keywords: topembed → topembed+

Comment 14

16 years ago
I think I have another case of this bug.  See bug 144326 for details.
(Assignee)

Comment 15

16 years ago
mass futuring of untargeted bugs
Target Milestone: --- → Future
(Assignee)

Comment 16

16 years ago
another link that shows this problem:

http://warp.mcom.com/embedding/groups/embedrock/embedrock_hike_2002/index.html

Comment 17

16 years ago
The Customer Management Interface (CMI) of iBill.com, one of the world's largest
ecommerce transaction processors yada yada, also fails with pipelining on. 

http://cmi.ibill.com/cgi-win/ccard/cmi.exe

The images that pipelining disables are crucial to the navigation of the
interface; without them the CMI won't work at all.  

The CMI is used by all iBill vendors, so it has a fairly large audience.  
(Assignee)

Comment 18

16 years ago
joseph: can you please try out a trunk build.  looks to me like iBill.com is
running Microsoft-IIS/4.0 which is known to behave badly when pipelining is
enabled.  mozilla trunk builds will not pipeline requests to a IIS/4.0 server.

Comment 19

16 years ago
Re #17, I just tried 2002052809-TRUNK and it works fine.

Comment 20

16 years ago
Ditto for me, via trunk 2002052803, iBill's CMI is no longer hamstrung with
pipelining on (#17-19).

Thanks

Comment 21

16 years ago
I'm getting a similar problem with http://www.thetrainline.com/ - this is a
major site in Britain for getting train tickets. Go to the site and click on
"register". The server never downloads the images (sometimes it fails to get the
page). This is over an SSL connection. I'm using Mozilla 1.0 on Linux here.

Comment 22

16 years ago
I'm seeing this on a trunk build, ID 2002061204 under w2k when connecting to an
Apache 1.3.24 server.  Same deal - with pipelining enabled the images take a
long time to load and some don't display at all.  The images (all of them) load
very quickly when pipelining is disabled.  The page (and server) in question can
be seen at http://www.burlco.org/pipe/ - this is a test case consisting of a
page with 10 identical images on it.  The server logs after viewing this page
with pipelining enabled indicate that Mozilla seems to be trying to load some
images more than once, after a delay:

x.x.x.x - - [12/Jun/2002:13:09:12 -0400] "GET /pipe/ HTTP/1.1" 200 524
x.x.x.x - - [12/Jun/2002:13:09:12 -0400] "GET /pipe/gif.phtml?1 HTTP/1.1" 200 876
x.x.x.x - - [12/Jun/2002:13:09:12 -0400] "GET /pipe/gif.phtml?2 HTTP/1.1" 200 876
x.x.x.x - - [12/Jun/2002:13:09:12 -0400] "GET /pipe/gif.phtml?3 HTTP/1.1" 200 876
x.x.x.x - - [12/Jun/2002:13:09:12 -0400] "GET /pipe/gif.phtml?4 HTTP/1.1" 200 876
x.x.x.x - - [12/Jun/2002:13:09:12 -0400] "GET /pipe/gif.phtml?5 HTTP/1.1" 200 876
x.x.x.x - - [12/Jun/2002:13:09:12 -0400] "GET /pipe/gif.phtml?6 HTTP/1.1" 200 876
x.x.x.x - - [12/Jun/2002:13:09:12 -0400] "GET /pipe/gif.phtml?7 HTTP/1.1" 200 876
x.x.x.x - - [12/Jun/2002:13:09:12 -0400] "GET /pipe/gif.phtml?8 HTTP/1.1" 200 876
x.x.x.x - - [12/Jun/2002:13:09:28 -0400] "GET /pipe/gif.phtml?7 HTTP/1.1" 200 876
x.x.x.x - - [12/Jun/2002:13:09:28 -0400] "GET /pipe/gif.phtml?9 HTTP/1.1" 200 876
x.x.x.x - - [12/Jun/2002:13:09:28 -0400] "GET /pipe/gif.phtml?10 HTTP/1.1" 200 876
x.x.x.x - - [12/Jun/2002:13:09:28 -0400] "GET /pipe/gif.phtml?8 HTTP/1.1" 200 876

...though there doesn't seem to be a correlation between images that don't
appear in Mozilla and images that appear more than once, or after a delay, in
the logs.  
(Assignee)

Comment 23

16 years ago
rcummins: you are actually seeing an apache bug related to CGI scripts and
pipelining... see mozilla bug 145392.
(Assignee)

Comment 24

16 years ago
http://online.wsj.com/public/us WORKSFORME linux build 2002-06-17/21

some of the other links mentioned in this bug, however, still cause problems.

Comment 25

16 years ago
The same problem occurs at http://www.comhem.se . With pipelining turned on,
I've let the page load for about half an hour, and still all images are not
showing. With pipelining turned off, the site loads as expected. I'm on an
ADSL-line.

Updated

16 years ago
Blocks: 144480

Updated

16 years ago
No longer blocks: 144480

Comment 26

16 years ago
WinXP 2002070602:
None of the images on http://www.tf1.fr/news are loading with pipelining enabled
and the page never finishes loading. This is always reproductible.

Comment 27

16 years ago
*** Bug 156644 has been marked as a duplicate of this bug. ***
*** Bug 156999 has been marked as a duplicate of this bug. ***

Comment 29

16 years ago
*** Bug 158849 has been marked as a duplicate of this bug. ***

Comment 30

15 years ago
This seems to be working now with a trunk build
I've tried almost every dupe or URL in this bug and they all worked for me
with 2002092710 trunk and HTTP pipelining. So this bug may be fixed or HTTP
pipelining doesn't work anymore

Comment 31

15 years ago
I concur with Bernard......is pipelining enabled on Trunk builds? It's set to on
in my Prefs.
(Assignee)

Comment 32

15 years ago
pipelining is still present on the trunk.  however, we recently added IIS/5.0 to
our pipelining blacklist since it proved to screw up in some situations. 
perhaps these sites are either running IIS/5.0 or perhaps they have upgraded to
a better webserver since this bug was originally filed.

resolving WORKSFORME
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME

Comment 33

15 years ago
yes, that appears to be the server being used in the original url

0010  0A 53 65 72 76 65 72 3A-20 4D 69 63 72 6F 73 6F   .Server: Microso
0020  66 74 2D 49 49 53 2F 35-2E 30 0D 0A 43 6F 6E 6E   ft-IIS/5.0..Conn

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

Status: RESOLVED → VERIFIED

Comment 34

15 years ago
Out of curiosity, is there a list (or a program ref) that lists which HTTP
servers don't work well with Mozilla pipelining?

Comment 35

13 years ago
I'm still seeing this bug using FF with pipelining.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040929
Firefox/0.10

Updated

9 years ago
Duplicate of this bug: 117475
You need to log in before you can comment on or make changes to this bug.