My PhoneGap app is built with jQuery mobile and currently I'm testing on Android. Cross domain parameters in jqm are set and I use a wildcard for the phonegap "access"-origins. The app uses AJAX for some JSON-communication. Now all ajax GETs seem to work without a problem, but about 40% of the POSTs never reach my server (i.e. not even headers, logs show no signs of those posts). All the posts are very basic ajax calls to exactly the same address, with some minimal json-load, like an id and some short value. I am using the Chrome device inspect and can confirm the posts are looking consistent, but about 40% of those posts keep the status "pending" and will eventually timeout.
I've read something about caching, post-data is always unique, but I've added nocache-headers to the servers responses. Posts should never be cached imo, but this didn't help me anyway.
The bare jqm-app works fine in the browser. Embedded in phonegap, some posts fail.. does anybody have a clue?
Try adding these options to your jQuery.ajax calls
dataType: 'jsonp',
cache: false
The first one allows cross domain posts and the second ensures that each request receives a unique parameter circumventing browser-side caching
Ok, I've set up a second test project with only the functionality of sending ajax requests, both post and get, on short intervals (like 2s). Turned out that gets where getting timed out too and after a few iterations, everything just timed out.
Lately I've been experiencing Chrome-crashes while developing, so I set up my server to do some well-arranged logging. I didn't start the app from Eclipse this time, but disconnected my phone and started it manually on the phone itself. Guess what: everything just works fine, all ajax requests arrive at the server.
I had already tested without the Chrome DevTools device inspect, but with the phone connected to usb: didn't help. But Chrome crashing quite frequently still makes me suspect it has something to do with it while connected to the pc.
Update:
I ran into problems again when sending some larger requests, like images in base64. Now I set header "Connection: close" on my server and things seem smooth again, even with Chrome DevTools inspect, except for the crashing of Chrome.
Related
I have a Flutter application and it makes some HTTP requests to my server. However, once in a while (not sure when, but I have seen it several times a day), when I open my app, the HTTP requests that happen during the first few seconds all report the error of SocketException: HTTP connection timed out (the source code that throws this seems to be here). However, after the first few seconds, other HTTP requests will succeed.
I have tried hard reproducing it but failed. Usually this bug happens, when I put my phone there for some time and then open the app (but it is not a thing for sure; also in many cases such behavior will not trigger the bug). If the bug happens, and I close the app and reopen it immediately, it will run very well and the bug will not happen again.
I have also used Wireshark to try to look at the network packages. However, when I setup the environment as "my app (in my phone) connects to my computer with development server using wifi and http", that bug seems to never appear again. Only with the production environment "my app (in my phone) connects to a server in the cloud using https" that this bug happens. But in that case I cannot use Wireshark to look into the packages.
I know I do not provide a reproducible sample, but I really cannot find out any clues. I even cannot stably reproduce it :(
I would truly appreciate it for any suggestions!!!
I had faced this issue in one of my initial projects, which usually happens with HTTP package, I'll recommend you to try this package:
https://pub.dev/packages/dio
And if you are an android developer then you may know it is the best combination to use dio with retrofit
https://pub.dev/packages/retrofit
This is an very, very strange problem.
We got an app based on Titanium SDK (version 7.4.1 I think), which gets it's data via an API to from our servers. These connections are running with TSL and basically, it works. But: Some connections do not receive data, they just run into a timeout.
I did some debug on this and this resulted in an even more strange thing: The working connections work really fine, but the non-working doing strange things. App connects to the server, server sends ACK. After this, app sends a ClientHello and receives an ACK - but nothing follows. The app is waiting for the ServerHello until the connections times out. This is all from a tcpdump.
So I created the same dump on server side, and here it starts to get really strange: For the non-working connections, the initial handshake is there. But the ClientHello is not received by the server.
This leaves me baffled, because the app is getting an ACK for sent ClientHello. Who TF is sending this, when the server never received any? It's an VM within a larger cluster - maybe it's ACKed before it reaches the VM?
Because I mentioned Titanium as well: The problem ONLY occures on Android. The iOS version of the app (with same code) is not affected!
Any ideas from anyone? All input is highly appreciated.
Probably, the title of the question is considered as not a valid question but we have spent 4-5 days debugging the issue. Here is the context:
We have an Hybrid app (Ionic3 + Cordova)
We have a Telecom Network Operator in Europe
We have provided them a URL to be whitelisted which is header enriched (by that Telecom operator) with user's mobile number whenever that URL is hit when user is using the mobile network of that operator
That URL must be a http URL not https
So we added a Angular HTTP interceptor in our codebase to convert https to http for that URL only
The Android mobile app hits to that URL as soon as the app launches
Now here is working/expected behaviour:
When app is launched freshly (was not in background or was killed by the home screen), the app hits that URL and the network operator identifies that URL and we receive the mobile number of the user.
Here is the scenario which is not working:
Now, we press the back button in Android and exit the app gracefully. That means Android app is in background & killed. Now we again launch the app from the app's icon and that header enrichment doesn't work.
Now, we added various tcp level logs using tcpflow command:
sudo tcpflow -i eth0 port 443 -C -e http
sudo tcpflow -i eth0 port 80 -C -e http
And we identified that whenever the app is relaunched from background (hence hitting to that URL), the entire request is encrypted but the URL we receive is http URL and the port is 443.
We added various logs in our http interceptor and in the Android phone but we are not able to identify the root cause. Can someone point a different direction to look for the issue.
Edit 1:
Tested on 5 different devices with different Android OS and device manufacturer
Android app is a release build
After another research of the full day, I was able to figure out the root cause of this problem.
Here I got the issue following the clues (in case someone gets help from it):
I got to know about the launchMode type of Android app
I stared Googling with Android's launchMode and this http encryption
I landed to a blog post reading Android O to drop insure TLS version fallback
I Googled more about TLS version fallback
Googling different keywords, led me to Android 8.0 Behavior Changes where I read about Networking and HTTP(S) Connectivity where I saw a new concept (for me) i.e. TLS renegotiation.
I started reading about TLS renegotiation and started relating it with Nginx & it's change logs so I figured out this is something related to Nginx & HTTP communication.
Till this point of time, I was only looking at the HTTP block in Nginx server configuration but I took a look at HTTPs block in Nginx and saw a unclear (to me) header configuration Strict-Transport-Security which was set to max-age=31536000 always
I dug about this header configuration and entire issue got cleared up immediately in my mind that this is not an issue, this is the default behaviour that when a browser see a successful HTTPs request and see that header, the next non-HTTP request is by default attempted with HTTPs and that was the issue we were having.
I removed the header (first reduced it's value to just 10 millisecond, so browsers can take effect) and tested my app with the same scenario, everything started working as expected.
I built a website in Shopify, see it here: practicalamerican.com
The site loads fine on desktop, mobile, wifi, every carrier - except AT&T. In the later case, the browser gives an error that there is no internet connection. Presumably, it never receives a response from the server, so it makes that determination.
Loading any other site works fine. I've confirmed this on multiple devices and multiple browsers, Android and iPhone. Weirdly, if I toggle Wifi on my iPhone and load the page, then toggle Wifi off and try to reload the page, it loads fine. Perhaps some sort of browser caching? Not sure how it would determine it has an internet connection as per the previous point.
I've tried: adding <meta http-equiv="Cache-Control" content="no-transform">
I've tried deleting every script tag to which Shopify gives access.
I've tried accessing practical-american.myshopify.com (bypassing the DNS record).
All with no success. Any other ideas?
UPDATE: I tried using a proxy, per this answer and I can view the page fine. Perhaps this is a DNS record caching issue with AT&T? Hopefully, it will clear soon. It's Black Friday right now, we just emailed 10,000 customers!
The issue cleared about 72 hours after it started. That seems consistent with DNS caching, as suggested by Ira. The other proof is that when the page was loaded on Wifi, I could then reload it on LTE, but I could not load it on LTE in an empty browser tab.
When I test the ionic app on a real device the REST calls are taking too much time, which actually will prompt the user to close the app. But on the developing stage, it works fine on local browsers using the command "IONIC SERVE". The same internet wifi connection is using on both android phones and developing computers. A sample rest Call used is
$http.get(newsurl).success(function(data){
$scope.news=data;
})
Did anybody face a similar problem?
There was an infinite scroll option in a window which was creating too many ajax requests to server. and when i moved between different tabs in the app number ajax calls was increasing, Too much ajax request are getting blocked.
I just showed a loading window while processing an ajax request so that users cannot move between tabs while ajax request are processing