Hello, is it possible to close all open HTTP connections from the client? I have various parts where I am doing <img src> which implictly call an http.get. I’d like to close all open connections in a sort of flush operation. I can’t use timeouts. I really need a way to basically clear off all connections. Is it possible?
the $http-service has an option called timeout.
there you can pass a promise object. --> if you resolve this promise and the request is pending it gets aborted.
Example:
if you have a service to make request to an api, which uses the $http-service.
create in your controller or where you are using this service a new deferred-object with $q.defer(). Pass this to your service-functions as a parameter. your service-function sets the timeout option with this promise.
So you can cancel the request in that code part you called it.
if you want to cancel a request from everywhere like the first controller calls the service-function and a second controller wants to cancel it you have some approachs to go:
- create a promise in the service function when the method gets called --> add a second function to cancel a possible request (so you can call this function from everywhere --> keep in mind to store the promises in your service
) - Broadcast or emit an angularjs event to let the second controller or codepart informing the first controller to cancel the request.
@bengtler some more details about my problem - the HTTP connection is due to image src tags. I am not calling http.get directly. More details:
I have a view that basically does this:
<div ng-repeat="monitor in monitors">
<img ng-src = 'http://myserver.com/cgi-bin/videoFeed?id={{monitor}}' />
</div>
Each monitor is actually an IP camera and what we are doing here is transmitting live feed as continuous JPG images (multipart/mime). -> the server keeps pushing new images over this connection.
What therefore happens is the img tag keeps showing new images continuously making it look like a live video feed
The problem I am facing is when we exit the view, it looks like angular still keeps the HTTP connection open and the server keeps the connection open on its side as a result. The server launches an instance of ‘videoFeed’ per connection, and I can see the instances don’t go away even long after (15-20 minutes) I exit the view. So I need a way to chop off these connections as soon as I exit so the server can kill its handlers too.
the problem is that you can not cancel those request from client side
For such “feed”-streams you should use web sockets. so the server can handle it when the client should get new data.
If the app gets closed or something like that --> the server will be informed and the connection to that client will closed automatically.
Or you should implement this as a real videostream and not for images.
bengtler is completly right a good alternative should be web sockets.
I am using it in several apps and runs pretty well
But just one advice , you should implement carefully to not overload the application.
I use the onEnter and OnExit in states to open and close to websocket and make sure if i change the view the socket is closed.
.state("camera", {
url : "camera"
controller: "example as ex",
onEnter: function($websocket){
//open it
},
onExit: function($websocket){
// close it
}
})
You can also provide a real feed of your images using that . When you change view (camera) you can open and close connection. in my case i just ws use for a specific part of my app.
1 Like
Thanks both. I’ve been reading RFC 6455 that hold the current (and evolving) flavor of WebSockets. What it really seems to me is it starts with HTTP (like the way it is now) and then switches to a light-overhead-on-top-of standard Sockets interface (but not with all the flexibility of sockets so it is confined within the browser sandbox model) that allows for bi-directional communication as and when it happens. I get the advantages of it over a pure HTTP solution.
However, specific to my case:
a) Using web sockets will require server support - which currently does not exist (I don’t control the server)
b) Let’s for a second assume that we do extend the server to support web sockets:
-
For the purpose of video streaming as images (multipart/mime) why is it better? Once a persistent HTTP connection is open, images are being sent as payload within the exisisting HTTP connection as chunked encoding
-
I still don’t understand why the client can terminate a web sockets connection but not an HTTP connection proactively. They are both, at the end of the day, an abstraction on top of a TCP socket fd. So why is it that if I move to web sockets a client can terminate the connection proactively while it cannot with HTTP without closing the browser?
thanks
Because media-requests are started from the browser and not from the web-app or app.
if you would start the request on your own, e.g. $http-Service, you can handle it like i said (via timeout).
You can try cancel it --> remove the image-tag from the dom with ng-if, but i think the browser will keep the connection open in the background
Absolutely correct. Removing it from DOM has no effect.
So to summarize:
a) Only way to solve this is to not use img src directly, but to use my own http request via $http. That however returns binary data. To display the image, I need to base64 encode it. The performance will likely be inferior to using a img src tag (as the browser would have likely used it optimized native library to do this, but can’t say till we try)
b) The entire discussion of web sockets does not seem very relevant here as we are talking about a continuous streaming image - I don’t see how moving to ws/wss will help
Would that be accurate?
to b)
it would help because you do not need an “image-stream” then.
Imaging this:
- client registers at server as socket-client
- user goes to image page in your app
- app sends request over sockets to get the first image
- gets repsonse and shows image
- server informs client about a new image and sends the new image-url automatically
- client can change the ng-src of the image
So you only have one socket connection and not an endless open http-connection.
1 Like