915755 - mjpeg stream - tcp connection will be never closed on server

Status: UNCONFIRMED

(Core :: Graphics: ImageLib, defect)

Description

[Stefan]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130814063812

Steps to reproduce:

1. i open a mjpg stream in a img tag 
2. go on server side and show the netstat result
     (netstat -an | grep -i 'myClintSideIpAddress' | grep -i CONNECTED| wc -l)
    CONNECTIONS = 1
3. set the img url to blank
4. CONNECTIONS = 1
3. set the img url to a fixed base64/jpeg string
5. CONNECTIONS = 1
6. set the img url to another mjpeg-url 
8. CONNECTIONS = 2
6. set the img url to another mjpeg-url 
8. CONNECTIONS = 3
9. remove img from parent
10. CONNECTION = 3
11. closing the firefox tab
12. CONNECTION = 3
13. closing firefox completly 
14. CONNECTION = 0

If i set the url to an blank url in chrome, the connection closed.
If i set the url to an blank url in firefox 23.0.1, the connection is blocked until i close firefox completly. 


Actual results:

The connections are blocked until i close firefox completly. 


Expected results:

The connection must be closed if i change the img url

Comment 1

[Stefan]

if number "network.http.max-persistent-connections-per-server" is reached. Every request are blocked and i must restart firefox.

My webapplication:
- 50 until 1000 security camera are save there images in a big storage 
- one server sends the images to the browser (over mjpeg)
- everytime if a stream is opend the url is changed. (url = /folder/PlayChangeable   sessionId?speed=1&...) and one tcp connection is blocked... until i close firefox

Comment 2

[Stefan]

new findings

If i open a "live-steram" to an windows server "172.27.8.104:4731?camera=bla"
the stream closed if i set the url to blank. Thats ok...

If i open a "playback-stream" on a linux server "172.27.8.106:9999/PlaySessionID?speed=0", the server cannot close the stream.
Thats my problem...

*live-stream: Play the live pictures from a camera.
*playback-stream: Starts a stream by a exact timestamp. The server sends the first picture and wait for user input.
*PlaySessionID: Every call creates a new unique ID.

Comment 3

[Stefan]

live-stream: On a WindowsServer with a unique ID also works...
-> "172.27.8.104:4731/timestamp/?camera=bla"

Comment 4

[Stefan]

Think that I have found it!
The problem is a stream that stops. The connection will close if the server tries to send a new image to the client and the client is unreachable.
In my case, the user presses the stop button and the server stops the streaming.
If you close now the firefox tab the tcp connection was not closed!

My workaround:
If the user presses the stop button, the server sends every second the same last picture.

Please note:
Firefox 20 stops the standby-stream automatically
Chrome stops the standby-stream automatically
Firefox 23.0.1 don’t stop the standby-stream automatically

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:aosmond, could you have a look please?

For more information, please visit BugBot documentation.