I am currently using the DefaultHttpClient to create an HTTP request to a rails server.
The network call is failing about 4% of the time with a SocketTimeoutException.
I have run Wireshark on my network traffic and discovered the following:
My successful call starts like this
And ends like this
The failed call starts like this:
And ends like this
Please note that the HTTP OK message that is sent to us from the server is missing from the end call, resulting in it timing out after about 15 seconds.
I am wondering if anybody has encountered this before or has any recommendations for debugging the Android Apache library or Apache rails to figure out why we are not receiving the HTTP OK message from the server.
I figured this out. The rails server and apache library were timing out if there were bad parameters in my post request. We were passing in a "_b" parameter, and for some unknown reason the server wouldn't like this and would time out the request. Removing the bad post parameter fixed the problem.
If anybody else is seeing timeouts like this, I recommend reviewing the POST parameters that are being passed in.
Related
TLDR: Is there a way to force OkHttp to correctly handle unexpected/unrequested 100 Continue HTTP responses?
I'm using OkHttp 3.8.1 on Android to POST to a poorly-behaved server.
Even though the request does not include an "Expect: 100-continue" header, the web server returns a 100 Continue response. Rather than continuing to send the request body, then getting the actual (200) response, OkHttp stops there and sends back the 100 Continue response in my okhttp.Callback.
I tried explicitly including "Expect: 100-continue" in the request to trigger OkHttp's logic, but the server (possibly due to some bug) claims the header is malformed and rejects the request. I also tried sending "Expect:" (no value), but the server still sends the 100 Continue response and OkHttp stops there.
Other HTTP clients (I've tested 3 so far) can talk to that server just fine. They handle the 100 Continue response correctly even though they didn't see "Expect: 100-continue" in the request header. Is there an option I can set, or an interceptor I can write, to make OkHttp do the same?
Sounds like something we can fix in OkHttp. This is weird and the server is broken, but if other clients handle it OkHttp should too.
Please report a bug there?
I have to use an restful API for my app in android, In this API we have to reverse proxy our app requests through our server( I use nginx proxy_pass for that), since the API only answers to one registered IP.
When I use curl to send a request through reverse proxy of nginx it works swell.
But when my Android app sends a request to it using loopj.asynchttp, onSuccessful fires but request status is 0, and body of answer is null, I'm totally confused. It returns no data so I could find out what is wrong with it.
In logs of nginx requests from the mobile appears, so the request certainly reaches to my server, but the answer returned is problematic.
These kinds of problem occurs when the server or loopJ closes your connection.
it has several reasons:
Firewall
LoopJ's time out
enginx's time out
for first reason, it depends on your firewall, but it's so easy to configure it.
for loopJ's time out, you can use setTimeout function like following code:
AsyncHttpClient client = new AsyncHttpClient();
client.setTimeout(//connection time you need as an integer);
you can use following link to set your nginx time out configuration:
click here!
I hope these tips help you.
I am re-implementing an existing worklight system. We have already have a hybrid version. We have decided to re-implement the Client side in pure native. The native client seems work fine.
However, the server seems to be quite unstable - sometimes we don't get a server response after invoking an adapter, sometimes we do get. I have checked the DDMS/Android console. And a Error/Exception was found. Any comments would be appreciated!
com.worklight.common.Logger$SendLogsRequestListener(4274): Logger$SendLogsRequestListener.onFailure in Logger.java:1726 :: Failed to POST data from file /data/data/${APP_NAME}/files/analytics.log.0.send due to: HTTP response code: 500
On a successful adapter call or WLClient connection to the server, the client will attempt to automatically send logs to the server. It looks like something bad is happening on the autosend for adapters. A temporary workaround would be to disable this auto sending behavior by calling
WL.Logger.setAutoSendLogs(false)
But you can only use this call if you do not wish for logs to be sent automatically. If you do wish to have this working properly, I'd suggest opening a PMR so that it can be determined if this is an error in your application or an actual defect.
In my android app i keep getting timeouts in the messages between the app and my server.
In an attempt to see if the problem is in the app or my server,
i want to try and Send an HTTP request from my app to
some other server i am sure is up and reliable and then see if i get timeouts.
Is there any server address i can check against?
Thanks in advance!
BTW : i am using a glass Fish servlet for my server
We've successfully sent a simple HTTP GET to google.com -- with a couple of fall-backs (I've also seen internic.org used) in the past, in similar cases.
I'm writing an HTTP client in Android that connects to glassfish on my localhost and sends some json information to the server.
I use:
UsernamePasswordCredentials cred =
new UsernamePasswordCredentials(SettingsHelper.mUser, SettingsHelper.mPwd);
client.getCredentialsProvider().setCredentials(AuthScope.ANY, cred);
for authontication, and making a put request.
The problem is sometimes, the client sends an unauthorized request before retrying and sending an authorized one, and on the second time, it pushes the json entity, before getting a proper response from the server (100 - continue). then, the server doesn't respond at all, and everything hangs.
i will note that sometimes it works.
Has anyone else experienced this problem? How might I resolve it?
finally managed to make it work with basic pre-emptive authontication.
example here