If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

VERIFIED WORKSFORME

Status

()

Core
Networking: HTTP
P3
normal
VERIFIED WORKSFORME
16 years ago
4 years ago

People

(Reporter: Tom Everingham, Assigned: Nivedita (gone))

Tracking

({topembed+})

Trunk
mozilla0.9.9
x86
All
topembed+
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 obsolete attachment)

(Reporter)

Description

16 years ago
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

Updated

16 years ago
Priority: -- → P3
Target Milestone: --- → mozilla0.9.9

Comment 1

16 years ago
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

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

Comment 3

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

Comment 4

16 years ago
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

16 years ago
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)
Blocks: 42224, 97683

Comment 6

16 years ago
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 :(
*** Bug 115021 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 8

16 years ago
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

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

Comment 10

16 years ago
-> badami
Assignee: darin → badami

Comment 11

16 years ago
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

16 years ago
Ack!   Please disregard comment #11
(wrong bug)

Comment 13

16 years ago
Nivedita already has a patch for this.
Assignee: badami → nivedita
(Assignee)

Comment 14

16 years ago
Created attachment 69213 [details] [diff] [review]
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

16 years ago
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

16 years ago
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

16 years ago
darin and rpotts, please r=/sr= this.

Updated

16 years ago
Keywords: topembed+
(Assignee)

Comment 18

16 years ago
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.
Attachment #69213 - Attachment is obsolete: true
(Assignee)

Comment 19

16 years ago
comment 18
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 20

16 years ago
verified wfm:  3/28/02 builds - win nt4, linux rh6, mac osX
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.