106166 - multipart/x-mixed-replace web cam site not updating

Status: VERIFIED WORKSFORME

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

Description

[Tom Everingham]

Overview Description:  This site is pushing out web cam images very quickly. 
The  camera images are sent out ok when using 4.7x (http 1.0) but neither images
or boundary tags are being sent for 6.x.  

Steps to Reproduce:
1.)  go to url

Actual Results:  no camera image appears

Expected Results:  should see a web cam image updated approximately every second 

Build Date & Platform Bug Found:  Win NT4, mac osX - 10/20/01 branch builds

Comment 1

[Daniel Ceregatti]

This was working just fine in 0.9.5+ in Linux, then stopped working in 0.9.6.

It displays the first image and stops. No streaming.

URL: (May not always be available)

http://daniel.omnis.com

Comment 2

[Darin Fisher]

gagan: perhaps this is related to your recent changes to the multipart stream
converter?

Comment 3

[Gagan]

AFAICT the site does not send any boundaries... just raw data. Not sure what's
going on with 4.x. 

Comment 4

[Daniel Ceregatti]

Try this (on a machine with wget, of course):

wget -s -O file
"http://sh.nu:82/cgi-bin/nph-tv?channel=7700&input=0&height=180&width=240&norm=1&quality=50&dev=video11"

or

wget -s -O file http://daniel.omnis.com/qcam?update=serverpush

Hit CTRL-C to stop them, otherwise they'll never stop.

Then open "file" in a text editor. You will see that the sites do in fact send
boundaries.

In Netscape 4.x, both URLs work fine. In mozilla 0.9.6+ for Linux, they no
longer work, but they did in 0.9.5.

Please note that the first wget command line points to a program that can only
handle one connection, so if you get a "camera is busy", try again later.

This also leads to another bug in mozilla where changing the location in the
browser does not instruct the web server to terminate the program that generates
the stream. I know there's a bug regarding that issue too, but I can't find it.

If you want to speak to me directly regarding this, I'm Primer in #mozilla (on
irc.mozilla.org)

Comment 5

[WD]

Bug 42224 and bug 97683 describe the problems Mozilla has been having with
multipart JPEG images, but yes, as described here it seems totally broken
lately.   (No streaming at all...  just initial image)

Comment 6

[slava]

http://camserv.base.1plus1.net/?quality=1&size=1&multi=1
I was check with telnet - its send boundaries.
After telnet it sending new images with boundaries but Mozilla display only the
initial image :(

Comment 7

[Matthias Versen [:Matti]]

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

Comment 8

[Tom Everingham]

this is behaving differently than when I oringinal saw it.  I am also now seeing
data and boundaries being sent but browser stuck on initial image.  12/12/01
WinNT build.

Comment 9

[WD]

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

Comment 10

[Darin Fisher]

-> badami

Comment 11

[WD]

It looks like creating a new window after viewing any page with java will do it.
Repro:

1) Go to http://www.javasoft.com
2) File -> New Window
3) Try to type in a new URL

Comment 12

[WD]

Ack!   Please disregard comment #11
(wrong bug)

Comment 13

[Vinay Badami]

Nivedita already has a patch for this.

Comment 14

[Nivedita (gone)]

Attachment: patch file for fixing the boundry token in multipart/x-mixed-replace

FindToken was always returning nsnull, as the mToken comparing the boundry from
stream was failing. This was because, the boundry token in the content-type
header does not have the preceeding "--", but the start of the data starts with
the boundry token with preceeding "--". Hence the check FindToken was failing,
which would end in not calling SendData. 

Added the preceeding "--" to the mToken, so that FindToken does correct
comparision of the boundry token.

Comment 15

[WD]

The patch for this bug alone did not seem to fix the problem, but if applied
along with the patch from bug 42224 it does seem to be fixed.

Pages with "Streaming JPEG" are actually streaming now.

Comment 16

[WD]

An interesting note:

I tried building Mozilla with only the patch from bug 42224 but without this
one.   The behavior is the same.   JPEG Push works either way.   Does this patch
actually do anything?

Comment 17

[Stuart Parmenter]

darin and rpotts, please r=/sr= this.

Comment 18

[Nivedita (gone)]

Comment on attachment 69213 [details] [diff] [review]
patch file for fixing the boundry token in multipart/x-mixed-replace 

Currently in FindToken, mToken, check does mandate for exact boundry value and
not the boundry value with preceeding "--". On success of boundry match, check
is made if the boundry from the stream had preceding "--", if yes, then mToken
is pre appended with the "--". 

This patch was pre appending the "--" to mToken right in the start i.e. once we
fetch the boundry from the header. Hence the check in FindToken would get
validated at first go and return aCursor.

Hence, streaming of Jpegs would work by just applying the fix of bug 42224.

Comment 19

[Nivedita (gone)]

comment 18

Comment 20

[Tom Everingham]

verified wfm:  3/28/02 builds - win nt4, linux rh6, mac osX