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
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
gagan: perhaps this is related to your recent changes to the multipart stream converter?
AFAICT the site does not send any boundaries... just raw data. Not sure what's going on with 4.x.
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)
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. ***
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.
*** Bug 112826 has been marked as a duplicate of this bug. ***
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
Ack! Please disregard comment #11 (wrong bug)
Nivedita already has a patch for this.
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.
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.
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?
darin and rpotts, please r=/sr= this.
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.
verified wfm: 3/28/02 builds - win nt4, linux rh6, mac osX