We have a specific URL that we use within our mobile apps to determine internet connectivity. This URL is proxied through Cloudflare and has a page rule which ensures the response is cached for a long time. The origin of requests to this URL is a public AWS S3 bucket. The full HTTP response should fit easily within one packet. Whether the response is cached or not, the response should be very quick and I would expect very few clients to close the connection before a response.
Over the last 24 hours around one third of these requests have resulted in HTTP 499 errors, making our mobile app act offline.
Many other URLs seem to be affected, although at a much lower rate than this one. Where I can match up the occurrence of this, I am not seeing any sign of those requests making it through to our origins.
Has anybody else experienced this and have a solution?
A small update here:
We’ve had a few more members complaining of similar connectivity problems. Many of them seem to be on the EE network, and for these members I’m not seeing any POST requests getting through to us. Their GET requests are coming through fine though
I am seeing in the dashboard analytics HTTP 499 errors on the paths that our app is attempting to call
So it’s nothing to do with EE. It was just a coincidence that many of the affected users were using EE. Over the weekend we’ve had several recurrences of the issue.
Can I get some @MoreHelp with ticket 2213506 please.
Could you share the domain and specific URL this is happening on?
Sure. The main culprit (and the one backed by S3 as described above) is
About a 30% of requests to this URL are ending up with a HTTP 499 according to the dashboard. I would expect almost all of these requests to be served directly by Cloudflare with no hit on the origin
There’s also a lot of the same errors on our API endpoints (
https://www.hiyacar.co.uk/api/v1/*) which seem to be mainly on POST requests, but a few GET requests.
We found the root cause of this, it turns out it was an issue with iOS when using a custom NSUrlSession configuration.
When the mobile device switches data connection (wifi → mobile, or even 4G → 5G etc) the NSUrlSession ends up in some sort of state where POST requests don’t fully complete, iOS is waiting on a response from the request it thinks has been fully sent and Cloudflare is waiting for the request to complete before handling.
As our timeout was less than the 100 seconds Cloudflare waits for a request to complete, our client was disconnecting and causing these HTTP 499 errors.
There is a little more information here in the Apple Developer forum.
We’ve re-written a lot of the networking code in our iOS app to work around this issue and released an update on Friday which has stopped this. Any recurrence of this over the weekend was resolved by our members updating their app, and you can see the reduction in the number of HTTP 499 errors over the weekend and the update rolled out.
@marcroberts Could you please be more specific on what you actually did when “rewriting a lot of the networking code”? The linked post in AppleDevForum does not really contain any information on how to solve the issue.
We had the same issue here and they disappeared instantly when setting our webservers back to http1.1…
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.