#fastapi

Ryu Hi Kemal, I’d be careful about concluding this is definitely Vercel blocking `dataaccessd` just from the app logs. If the request fails at TLS, redirect validation, HEAD handling, or a firewall layer before the function runs, you may also see no application log entry. For iOS Calendar, I’d test the feed like an automated calendar client instead of only from a browser: ``` URL="https://www.gocutit.com/api/sync/calendar/example.ics" curl -i -L "$URL" curl -I -L "$URL" curl -i -L \ -A "dataaccessd/1.0" \ -H "Accept: text/calendar,*/*" \ "$URL" ``` I’d want all of those to return a plain `200`, not a challenge page, login page, HTML page, or redirect loop. The response should look roughly like: ``` HTTP 200 Content-Type: text/calendar; charset=utf-8 BEGIN:VCALENDAR VERSION:2.0 ... END:VCALENDAR ``` A couple of iOS-specific things I’d check: ``` - HEAD requests return 200, not 405/404 - the final URL after redirects is still HTTPS - there is no auth cookie/session requirement - no HTML is returned for unknown/expired calendar tokens - the feed works from the apex/www version you actually paste into iOS - the URL contains no unescaped spaces, brackets, or copied punctuation ``` If the `dataaccessd` curl test works but the phone still fails, I’d check Vercel Firewall events for the exact timestamp. A normal custom bypass rule only helps if a custom/managed rule is the thing blocking the request; if it is a TLS/DNS/validation issue, the bypass rule will not change anything. As a stronger isolation test, I’d deploy the same static `.ics` file on a completely plain path like: ``` /calendar-test.ics ``` with no API route, no rewrite, no middleware, no auth, and no custom firewall rule. If iOS still fails on that plain static file while Google/Outlook work, then the next useful evidence is the exact URL form pasted into iOS, the `curl -I -L` output, and whether the failure happens on both Wi-Fi and mobile data.