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?
Related
I have an android application and I am trying to make an http/2 call with okHttp version 3.13.1, in my case for one request I will be receiving two responses sequentially from the server, but with the okHttp client I am getting only one response and if I try to send the request using curl command I am receiving two responses sequentially from the server.
Is there a way to handle multiple responses for a single http/2 request in android?
I tried various ways, but no luck:( Would be more than happy, if anyone could provide your inputs.
Thanks for your help and time in advance!!!
I am basically sending a get request from my android application using okHttp client to a server which supports http/2, so expecting to receive 2 different response for that single request in a timely manner.i.e the second response will be sent from the server after 5 seconds gap of receiving the first response.
Below is my response :
First response
event:initialize
{"session_id":"df313001-6461-431c-bcc1-7cb931bda4f5","deviceId":"YL0012345678"}
Second response
event:voice_response
data:{"intents":[{"version":0,"intent":"telstra_intent_voice","params":{"voiceResponse":{"displayText":"Launching now","vuiFileName":"E03.01.P2.V01.E.wav"},"action":{"ecp":"/launch-install/71361"}}}],"deviceId":"YL0012345678","channelId":"269671"}
But, in my case once I receive the first response the client is no longer listing to the server. When I receive the first response, in my log I see :
com.example.okhttp3 D/OkHttp: <-- END HTTP (166-byte body),
so not receiving the second response.
Appreciate your help!
I found a workaround. You can send the response as multipart data. Then encapsulate all your responses into the multipart data seperated by 'boundary'. The multipart data will not end until you send the 'end mark'(0). Then the client side could decode all the responses one by one simultaneously when the server sending the multipart data.
The multipart data will looks like this:
--boundary
response_1
--boundary
response_2
...
--boundary--
0
there is also a demo here.
I have an api that returns an object as the response, and an etag and max age as headers. The response looks like this:
HEADERS:
'x-frame-options': 'SAMEORIGIN',
'x-xss-protection': '1; mode=block',
'x-content-type-options': 'nosniff',
'x-download-options': 'noopen',
'strict-transport-security': 'max-age=15778476000; includeSubDomains',
'access-control-allow-origin': '*',
etag: 'c69148a0489a95058e729bde7fd4bf32bf2077b1cba8d4fcf0c2da6e696fa33e',
'cache-control': 'private,max-age=43200'
BODY:
{
id: 1985,
url: "https://example.com",
...
}
The desired scenario is that an android application makes the request to ask for this data. The Api returns the data, along with an max age of 43200 secs.
If a request is made before 43200 secs pass, the application has the data from the last response cached. The application makes the request nevertheless, the back-end service compiles the response data, uses the request's etag to decide whether the response data has changed. If the data has changed, it returns a 200 http status and the data. Otherwise it returns a 403 status and no data.
The application receives the response. It uses fast networking to handle caching (says my android teammate). If a 200 status code was returned, the data are updated. Otherwise the application keeps the old data.
If a request is made after 43200 secs have passed, the application no longer has the cached response or it's etag. The request is made, the data are considered as 'new' even if nothing has changed in the data, the status code 200 is returned along with max-age header as above.
What actually happens:
For some reason, after the first request is processed and the application receives the data, no request is made until 43200 secs have passed. The android developer says they see that the request is made and 0 bytes are returned, but when I monitor the requests in the server I don't see any made towards this API.
This doesn't make sense, since max-age does not imply that no requests are made. It simply instructs the application to keep the data in the cache for the duration.
Am I missing the idea of how cache, etags and max-age work?
Back-end is built in node js, and uses express for routing.
You've only set the max-age and private directives in the Cache-Control header. The actual behaviour you have described is the correct behaviour since max-age directive has no bearing on forcing the cache to validate responses each time a request is made. For that, you have to add the no-cache directive as well to the Cache-Control header.
The no-cache directives tells the cache to always validate the stored response with the origin server before serving it (i.e., the desired behaviour you have described). Upon revalidation, the stored response will be valid for another 43200 secs (max-age). Without the no-cache directive, the HTTP client is free to make use of cached responses. Which I guess is why your friend said the request was made, but 0 bytes were returned (browsers also show 0 bytes for responses served from the cache). And which is also why you didn't observe any incoming requests to the server.
Have a look at this article from Google for a good overview on HTTP caching:
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching
If you need in-depth detail on how responses are constructed from caches, have a look at the RFC7234 spec: https://www.rfc-editor.org/rfc/rfc7234#section-4
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 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.