I am trying to generate lot of requests from my angularjs app to a backend rest server. I am using http service to make the calls. I want to control the concurrency of requests going to server.
I know that browser itself throttles the number of connetions per server.
Now my questions are:
How can I control the number of connections chrome opens to a server? How to do it using angularjs?
How does the angularjs http service works? Does it opens and close the http connection every time I make a http call? If yes then how can I create persistent connections in angularjs?
XMLHttpRequest is used under the hood. Since it uses HTTP, most of the answers to your questions are dependent on the headers you use and the server you are communicating with. For instance, whether or not connections persist depend on whether or not Keep-Alive is specified and the server supports it.
As for the number of connections, this is generally limited by the browser on a per domain basis. You won't be able to make use of more than the browser can allow, but you can probably write your own code to throttle it down if you so desire.
This question has good information about connection limits for the various browsers.
Related
I have an app engine service deployed in GAE (written in Node) to accept a series of click stream events from my website. The data is pushed as an CORS ajax call. I think, since the POST request can be seen in browser through the developer tools, somebody can use the app engine URL to post similar data from the browser console.( like in firefox, we can resend the URL. Chrome also has this features i guess)
A few options I see here is,
Use the firewall setting to allow only my domain to send data to the GAE.
This can still fail me since the requests can be made from the browser console repetitively)
Use a WAF ( Web Application Firewall) as a proxy to create some custom rule.
What should be my approach to secure my GAE service?
I don't think the #1 approach would actually work for you: if the post requests are visible in the browser's development tools it means they're actually made by the client, not by your website, so you can't actually use firewall rules to secure them.
Since requests are coming into the service after fundamentally originating on your own website/app (where I imagine the clicks in the mentioned sequences happen) I'd place the sanity check inside that website/app (where you already have a lot more context info available to make decisions) rather than in the service itself (where, at best, you'd have to go through loops to discover/restore the original context required to make intelligent decisions). Of course, this assumes that the website/app is not a static/dumb site and has some level of intelligence.
For example, for the case using browser development tools for replaying post requests you described - the website app could have some 'executed' flag attached to the respective request, set on the first invocation (when the external service is also triggered) and could thus simply reject any subsequent cloned/copy of the request.
With the above in place I'd then replace sending the service request from the client. Instead I'd use your website/app to create and make the service request instead, after passing through the above-mentioned sanity checks. This is almost trivial to secure with simple firewall rules - valid requests can only come in from your website/app, not from the clients. I suspect this is closer to what you had in mind when you listed the #1 approach.
Here is my scenario:
I am going to build a AngularJS webapp which requires to interact with multiple cross-domain server. There are two approaches:
Make all the requests from client side - From my understanding AngularJS enable us to build a rich client and make REST call to server to obtain data. However for this approach I have to handle CORS issue.
Moving those call to server side (Node.js) - Node.js makes all the calls to cross-domain server. It exposes REST API for AngularJS to request Node.js to make those calls.
Which approach is suitable for my scenario? Are there any criteria that can guide me to use which approach?
Those cross-domain resources are not maintained by me. I have no way to control their ways to provide resources. Also at least one of the resources does not support CORS. At this moment I config a proxy to handle those call.
When it comes to interacting with cross domain, you options are using either CORS or JSONP if supported by target server.
In case not the only viable option is to proxy the request through your own server.
You can make everything proxy through your server but that would require effort and time to implement.
I don't see any harm in doing the normal CORS or JSONP way for server that support it and use the proxy approach when the underlying infrastructure does not support it.
I am creating a web application using GAE/GWT. Front end GUI is a web client and the server is a RESTFUL server both running in GAE in different domains.
I am using json with padding to communicate with the server but discovered I won't be able to send a PUT/POST/DELETE request.
My application will be used to mainly used to query data (query: 85% of cases, modify data: 15%). All requests will be authenticated.
I am considering the following options.
1) For querying use JsonpRequestBuilder, for modifying create a proxy in the web client server side and hit the REST service through this proxy. Use GWT RPC to communicate to this proxy.
2) Make every request as a GET request in my REST service (including those that modify data) and use jsonp directly from web client.
I would prefer option 1) but option 2) seems less work to do.
Should 1) be my preferred option ?
Are there any problems with 2) given all my requests will be authenticated. ?
Is there any other easy approach to solve this problem ?
Regards,
Sathya
The simplest solution is to use CORS which allows you to send requests two different origins. But it is not so widely spread (check caniuse), so if you have to support IE8-9, it will not be enough for you.
In your case I would try to implement dual solution (e.g. CORS + server proxy). If browser supports CORS - send the request directly to the target server, if it doesn't - send request via proxy.
Sorry to ask but what is the advantage to have your client running on a different domain ? From what I understand your client's server will do nothing ...
If you are not the "owner" of the REST backend, maybe this backend should developp an authorization system for third party applications, like oauth2.
Then your application can talk backend to backend with a secured connection. You can use scribe to do that on your backend.
I have an application that consists of a Windows Phone client sending HTTP requests to a Python server hosted in Google App Engine. In the GAE log, I see that I often receive multiple identical requests from the same client within a few milliseconds (see below). I never saw this behavior when testing the client in my development environment. Nonetheless I realize that this is probably error in my code, but my question is:
Can any part of the infrastructure (the mobile network, the internet, the google app engine itself) cause requests to be duplicated?
And if so, a follow on question is: are there best practices to minimize this?
No, HTTP requests are not be duplicated by the underlying infrastructure. At least they should not be.
What probably happened is that you see mobile app requests which are made in native cod and they do not use cookies and have same user agent string. The same IP is because mobile networks internally use NAT, hiding multiple (possibly thousands) clients behind a single IP address.
It's really not possible for the network to duplicate HTTP requests. It can duplicate IP datagrams with misconfigured routing, but the TCP layer filters duplicate IP datagrams so that the end to end connection only sees one TCP stream. App engine might reuse TCP ports without the standard time to wait for the previous TCP connection to die for performance purposes, but I still don't think duplicate packets would survive from the three-way TCP handshake used to initialize connections.
What are the usual patterns for bidirectional communication between a client and a server in a wlan environment. How is it possible for the server to push data to a mobile client over wlan after a connection has been established.
Lets say I have a webservice running on a server and the moblie cients in the wlan can use this webservice. Now the question is how can the server invoke methods at the client, or directly send data to the client. How is this handled usually?
I would apriciate some links to read about this topic.
Is this a common problem or is it not that easy to solve?
Cheers
HTTP server push (also known as HTTP streaming) is a mechanism for sending data from a web server to a web browser. HTTP server push can be achieved through several mechanisms.
More at http://en.wikipedia.org/wiki/Push_technology#HTTP_server_push
In web development, Comet is a neologism to describe a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it. Comet is an umbrella term for multiple techniques for achieving this interaction. All these methods rely on features included by default in browsers, such as JavaScript, rather than on non-default plugins.
More at http://en.wikipedia.org/wiki/Comet_(programming)
Also there is a recent IETF draft on
Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP
https://datatracker.ietf.org/doc/html/draft-loreto-http-bidirectional-01