When sending a GET request in Safari, Safari is failing to send a valid request to the server. In fact, it isn't even reaching the server (I've checked this on the back end). Its also failing to provide all but two of the request headers and the response is null (which results in safari logging a kcferrordomaincfnetwork error 303 in the console). I've attached some screenshots below along with some additional findings. Can anyone provide any insight?
Screenshot of the request when it fails
Screenshot of the request when it passes
Issue is only reproducible in Safari on iOS devices.
Issue was happening on the MacBook previously. After clearing the website data once, we never saw the issue again
The call is intermittently failing
When setting a breakpoint before the product details call and manually calling it in the console, it fails the first time and then passes the second time.
Sometimes it isn’t the product details call that is failing (although it usually is)
Sometimes it is the create app or get product image call that fails.
Issue seems to go away after clearing website data, but comes back after one successful session.
When the call fails, we are getting the following error in the console: kcferrordomaincfnetwork error 303
Session storage is empty and issue persists
No exceptions are occurring (I enabled "break on all exceptions" in Safari)
Try running ng serve with the --no-live-reload option. We were seeing similar behavior, and WDS may have been interrupting the HTTP calls. So far, this has solved our problem.
Related
I am doing a get API request and everything works fine, but I am getting the following warning in the console.
Task <13369ECB-128E-41B7-B9E4-DC7D3E47D0C1>.<2> finished with error -
code: -999
This only occurs for a certain API endpoint. This makes no sense to me at all. I thought -999 stands for cancelled request, but my requests are finished.
I think this might be a security issue simply because all my get requests work for multiple api endpoints, but not a specific one. Any suggestions are appreciated.
Yes, this means it was canceled, but the question is why
be patient to make sure you didn't cancel the request.
returned when an asynchronous load is canceled. A Web Kit framework delegate will receive this error when it performs a cancel operation on a loading resource.
may be caused by an invalid SSL certificate
I have an iOS app that authenticates to a remote API. The server gives back a token that is used for all the next requests. The authentication call is a simple POST to /api/auth.
My question is: where should I make this call in the app ?
I don't know if I should use it in the AppDelegete (willEnterForeground or didBecomeActive), because it may slow down the app launch. Moreover, this is asynchronous and if I try to make other requests in some controllers while the token hasn't returned, there will be errors.
So I thought about doing it in the root controller, but in the case the app was in the background for a long time and comes to foreground in another controller it doesn't work...
The last option would be to watch errors on every call, and re-authenticate when the server responds with a 'token expired' error. In that case I should probably have a special class for HTTP requests and error handling ?
I don't know what option is the best...
We use Twilio SDK in our iOS app. It works fine but sometimes didStopListeningForIncomingConnections callback is called with error=31000 ("General error"). After that, the device turns to a strange state: it seems to be online but it's impossible to call it. And it shows "unconnected" state on the device.
So the questions are:
1. What does this 31000 error means?
2. What should we do in such a case? How to reconnect device to Twilio?
Megan from Twilio here.
You can see what an error for Twilio Client means here: https://www.twilio.com/docs/api/client/errors
However, 31000 is a rather vague and less than ideal error message as you describe. In this case, it is likely that the Twilio capability token has probably expired while the application is in the background, and if you merely call the listen method whenever they are receiving the 31000 generic error, it might cause the client SDK to result in a error-retry loop and crash the application eventually.
At the time of your writing with TwilioClient iOS SDK v1.2.5, it is suggested to use the following sample code in your did-stop-listening callback:
- (void)device:(TCDevice*)device didStopListeningForIncomingConnections:(NSError*)error {
if ( [self checkCapabilityTokenStillValid] ) {
// if the token has not yet expired, use the `listen` method of `TCDevice` to resume the listening state
[self.device listen];
}
else {
// restart all over by requesting a new capability token and initialize/update the `TCDevice` instance again
[self login];
}
}
The TwilioClient iOS SDK takes care of dispatching the listen and updateCapabilitiyToken: methods to the current thread for execution, therefore it's safe to call them directly in the didStopListeningForIncomingConnections. The did-stop-listening delegate method is always triggered with dispatch_get_main_queue() of Grand Central Dispatch.
Hope this may help others if they run into the same generic error.
This may or may not be the issue, we have encountered 31000 errors two times in our development and both were a result of generating the JWT on our server api. To be clear the error was a 31000 on the client, but the reason for this was in the construction of the JWT, and the params we wanted twilio to send back to our application.
When passing in an object to allow_client_outgoing or allow_client_incoming the twilio sdk concats this all in their scope attribute in their JWT. It added it to the scope:client:outgoing?appSid= which looks like a query string. That means it has a size limit of 2048. So exceeding this length generates a 31000 error.
In addition adding the objects doesn't seem to always implicitly serialize the object correctly, it introduces characters that can generate errors in their corresponding mobile sdks (but not their web sdk ... weird) so we took care of this by explicitly serializing objects to JSON before they are inserted into the JWT.
I hope both of these examples help you track down the issue.
On start app i called AudioSessionInitialize and check result value.
If it was kAudioSessionInitializationError then i informed user that application can not work properly cause audio does not work.
But since iOS 7 this function was deprecated.
It was similar question before: A fix for AudioSessionInitialize Deprecated? but... it has no any mention about how to get initialization error status.
And of course, i know how to initialize audio session without this function: Just calling [AVAudioSession sharedInstance] cause hidden call of AudioSessionInitialize. But it returns non zero value anyway. So new interface does not allow to get initialization error status.
upd: I'm not sure it's important but i receive message to stdout (which i redirected to log file) while call with error happens:
ERROR: [7971] 146: Unable to talk to server: error 0x10000003
(268435459)
explaination why i need this:
It happens very rarely (less then 0,1% of case) but it happens for any firmware. Last case registered for iOS 7.0.3 - so it's actual return value still (btw, first case registered for first firmware my app supported: iOS 2.2). It's important feature (cause i develop alarm clock) - it allows to know user about issues in the evening and not in the morning (cause in the morning this issue will cause oversleep).
In my app i am calling image from url,its working in simulator but in device it shows tunnel failure probelm. I then appended "deviceside=true" if i test it in simulator and "interface=wifi" if i test it in device both shows "Unexpected Response code 301" error. Why it is so ? Guide me.
301 is a "Moved Permanently" code. The actual body you receive will probably say where its actual location is. The browser gets this and can make sense of it, knowing to just forward itself to the new URL, but a normal connection is just grabbing the contents of whatever is at that location.
You can add some logic in there to follow the redirect, or just figure out what the actual URL is.