Bug: iCloud Public Calendar rejected even though URL returns valid VCALENDAR via GET

[TharpTravis]

Bug

Second Brain v2.1+ rejects an Apple iCloud Public Calendar URL with:

That link didn't return a calendar. Make sure it's the secret iCal (.ics) address, not the calendar's web page.

The calendar was shared exactly as documented in the Second Brain README:

iCloud → Share Calendar → Public Calendar

The resulting feed has been independently tested and is a valid iCalendar feed.

Environment

• macOS
• Second Brain desktop app
• Second Brain v2.1+
• Provider: iCloud Calendar
• Apple-generated URL format: webcal://pXX-caldav.icloud.com/published/2/[REDACTED]

The actual calendar token is intentionally redacted because the public-calendar URL provides read access to the calendar.

Steps to reproduce

1. Open Apple Calendar on macOS.
2. Select an iCloud calendar.
3. Enable Public Calendar.
4. Copy Apple's generated webcal://... URL.
5. In Second Brain, open Connections → Calendars → iCloud Calendar.
6. Paste the URL.
7. Click Connect.

Second Brain rejects it with the error above.

Changing webcal:// to https:// produces the same Second Brain error.

Diagnostic results

HEAD request fails

Converting the URL to HTTPS and issuing HEAD:

curl -L -I 'https://pXX-caldav.icloud.com/published/2/[REDACTED]'

returns:

HTTP/1.1 400 Bad Request
Server: AppleHttpServer
Content-Length: 0

Using HTTP first produces:

HTTP/1.1 301 Moved Permanently
Location: https://pXX-caldav.icloud.com/published/2/[REDACTED]

and following that redirect ultimately gives the same 400 for HEAD.

GET succeeds

A normal GET against the exact same calendar succeeds:

curl -L -s 'https://pXX-caldav.icloud.com/published/2/[REDACTED]' | head -10

Output:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//caldav.icloud.com//CALDAVJ 2628B761//EN
X-WR-CALNAME:[REDACTED]
X-APPLE-CALENDAR-COLOR:#FEC309
BEGIN:VEVENT
DTEND;TZID=America/Los_Angeles:20160518T120000
UID:[REDACTED]
DTSTAMP:20160518T174532Z
LOCATION:[REDACTED]

So the iCloud endpoint is accessible and returns valid iCalendar data when fetched with GET.

Suspected cause

The calendar validator may be doing a HEAD request before GET and rejecting the calendar when Apple's published-calendar endpoint returns 400 to HEAD.

Other possibilities:

• webcal:// isn't being normalized to HTTPS correctly;
• validation requires a literal .ics filename/extension, which Apple's published-calendar URLs don't have;
• validation rejects Apple's response based on HTTP metadata before parsing the returned calendar body.

The HEAD behavior seems particularly suspicious because HEAD fails while GET against the identical resource succeeds and returns BEGIN:VCALENDAR.

Suggested fix

For iCloud calendar URLs:

1. Normalize webcal:// → https://.
2. Don't require .ics in the URL.
3. Don't require HEAD to succeed.
4. Perform GET with redirects enabled.
5. Validate the returned body as iCalendar (BEGIN:VCALENDAR / END:VCALENDAR).
6. Pass the resulting body to the ICS parser.

This would support Apple's published-calendar URLs in the manner documented by Second Brain itself.

Happy to run additional sanitized diagnostics if useful.

[rahilp]

Thank you for this — the sanitized diagnostics were genuinely useful, and a report this careful made it quick to track down.

It turned out not to be HEAD. There is no HEAD request anywhere in the calendar path; it was always a plain GET, and both webcal:// normalization and the missing .ics extension were already handled. The tell is the error you quoted: that message is only reachable after a successful fetch with a body in hand, so iCloud had already answered you and it was our ICS parsing that gave up. Apple's published feeds carry an X-APPLE-STRUCTURED-LOCATION line whose continuation isn't folded the way the parser expects, and some feeds also lead with a UTF-8 BOM. Either one throws.

Fixed in #311, now merged. Both quirks are sanitized before parsing, redirects are followed explicitly, and a pNN-caldav host that doesn't return a calendar now retries once on pNN-calendars. Your suggested fixes were the right list — it just happened that most of them were already in place, and the real culprit was one layer further in.

This will go out with 2.3.2. I'll leave this open until that release lands, then close it out.

[rahilp]

1.3.2 is out with this fix: https://github.com/rahilp/second-brain-cloudflare/releases/tag/installer-v1.3.2

Update the desktop app, or redeploy the Worker if you self-host (SB_VERSION 2.3.2), and your published iCloud calendar should connect.

Thanks again for the report — the sanitized diagnostics saved a lot of guesswork. Closing this out, but reopen if it still gives you trouble.