I'm using Volley to make a server call, which can in some cases return a large response - a few megabytes JSON.
When the server response is more "normal" size, everything works, but with a large payload Volley throws a NetworkError without any details attached and logs a weird message - BasicNetwork.performRequest: Unexpected response code 200.
I'm pretty sure the issue is with response size, so my question is whether there a known limit for HTTP request/response size in Android/Volley, or a setting to change it. I know some HTTP libraries have it.
I know the server is fine as there are other clients using the same server endpoint in the same way.
I started debugging inside the library code and found that the response code is indeed 200 and the correct data is being received. The request content is being copied from response stream in chunks, but at some point something goes wrong in the copying.
This is the closest I could get to the original exception. Apparently, a java.net.ProtocolException is getting thrown sometime during the while loop at first breakpoint shown on the picture. You can also see the actual JSON content is there.
Then this exception gets handled and re-thrown a couple more times:
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?
When i call any webService with expired token,the service returns code 498 with error message "your tokken is expired"..BUT the retrofit gives the response code 500 with error message " internel server error".
response.code() //500 instead of 498
I tested the same url with postman and its working fine but the issue is only with retrofit.
I am using same services on IOS with AFNetworking and its also working fine there.
Any body can help to figure out why this is happening? thanks in advance.
This is not a full answer, but it's too big for a comment.
5xx codes are server errors, this means that the server is crashing, not the app nor is retrofit buggy. The issue most likely is in the server, but can be caused by retrofit - yes, that's true.
My experience with all the questions that say: "I tried this insert random network call here with postman and it works, but retrofit returns 500" is because postman adds headers by default, which retrofit doesn't. The server implementation then expects these headers to be set and due to a faulty implementation crashes if said headers are missing.
I would check the headers retrofit is sending and the headers postman is sending and compare both and make sure which one crashes the server.
It can also be that OkHttp (Retrofit uses OkHttp under the hood) is adding some headers which the server cannot cope with. This would be stranger to me, but not impossible. I think it adds for example by default gzip and some servers might not handle this correctly.
If you have access to the server, than it might even be worth checking there the logs. They might point you right away to the issue.
I'm sorry but I cannot point you directly to the problem. These are just tips to get you started. Hope they help.
I am study about doPost and get method to send data from android app to tomcat server.
I am trying to check the size of http request and response because I am sure that request and response was sending data and catching data from tomcat server.
I used this example ,
http://www.avajava.com/tutorials/lessons/how-do-i-determine-the-content-length-of-a-request.html
to check the contents length.
After I get contents length, i get two questions
First, contents-length represents whole size of http request ?
if it is not, then how can i check the size of http request (by bytes)?
second , I am still having a trouble to getting size of response ?
I tried
How to Get the HTTP Response Size in Java (in Bytes)
Determine size of HTTP Response?
but i was getting error to get size of http response
is there any way to get size of http response ?
thanks
No, it is not the size of the whole request. It is the length of the message body, excluding status line and headers.
Not all servers provide the content length. If you use chunked transfer encoding, the content length cannot be determined without downloading the whole response. If the server sends the "Content-Length" header, you can get the size of the message body. You need to hook the socket stream to get the actual (full) response size.
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.
i'm sending an http request to the google reader api and getting an unusual response code. following the documentation, i've requested an auth code and included it in the header of every request. after performing the login, and getting an auth code, i tried accessing this url, which is part of the documentation:
http://www.google.com/reader/api/0/stream/items/contents
when i send the request, i get a 411 status code, which is supposed to mean "Length Required". the length, as i've found, is supposed to be the length, in octets, of the message body. there is no message body in this request. there is only a single header, the POST parameter i="item id" and the URL itself. i tried setting the "Content-Length" header to "0" and also to "-1" to no avail.
what's really interesting is that this same code worked fine before google changed their authorization procedure. it's apparent they've changed something else...
so my question is what EXACTLY would cause a 411 response code and how can i prevent it?
This error happens only with POST and PUT request types, as these two (sort of) expect to have a request body that includes the request parameters (plain textual as well as attachments).
However as the documentation suggests, this is largely an obsolete value, and realistically the web services should handle requests without relying on Content-Length.
So it's not the problem of a request sender, but it is (I would say) a bug on the service side.
Nevertheless, setting a Content-Length (mind the proper capitalisation) request header to 0 should be the workaround.