Overcast/RSS: "Publisher Server Error"

Simon · June 24, 2026, 8:28am

Hey lovely people

Problem
Overcast (iOS) shows all Episodes of my Feed but when trying to download it just shows “Publisher Server Error” (see screenshot).

These is the problematic (patreon) feeds:

What’s weird about it

This problem only appears with Overcast and no other Podcasting App
My “normal” Feeds (non-patreon) DO WORK in Overcast (https://gamedevpodcast.de/feed/aac/ + https://gamedevpodcast.de/feed/mp3/)
When I diff both feeds, I only see the expected: different names/urls and of course itunes:block so that the Patreon feeds don’t appear in the search.

Does anyone have an idea what the problem could be ?

ericteubert · June 26, 2026, 9:11am

Sorry, can’t see any issues in these feeds, should work perfectly fine

Simon · June 26, 2026, 9:22am

Thanks for the reply! Interesting, I checked with another validator and there I saw this:

But I asked my provider and they said they support byte range.

Also interesting: The feed from our old podcast (https://textlastig.com/) stopped working on iOS as well and we didn’t change anything on it for a long time. It all happened in one of the last weeks. Very weird.

ericteubert · June 26, 2026, 9:36am

I’ll look into the byte-range issue. I feel like that has always been falsely reported but I haven’t looked at it in detail for a long time.

ericteubert · July 12, 2026, 1:56am

I looked into it but the implementation of the validator seems to be closed source. So I don’t know what they are checking but it is wrong. Here’s an example range request which works perfectly fine:

❯ curl -L https://textlastig.com/podlove/file/1218/s/download/tl254_nlp.mp3 -i -H "Range: bytes=0-127" --output -
HTTP/2 301
strict-transport-security: max-age=31536000
location: https://media.textlastig.com/tl254_nlp.mp3?ptm_source=download&ptm_context=&ptm_request=751efe1b6eb8&ptm_file=tl254_nlp.mp3
vary: User-Agent
content-length: 0
content-type: text/html; charset=UTF-8
date: Sun, 12 Jul 2026 01:53:30 GMT
server: Apache

HTTP/2 206
strict-transport-security: max-age=31536000
last-modified: Tue, 25 Oct 2022 21:14:24 GMT
etag: "38649ad-5ebe2647e2971"
accept-ranges: bytes
content-length: 128
vary: User-Agent
content-range: bytes 0-127/59132333
content-type: application/octet-stream
date: Sun, 12 Jul 2026 01:53:31 GMT
server: Apache

ID;TIT2M��TL254 - A Normal Lost Phone #5 - EndeAPICEimage/jpeg����J⏎

dnebannoS · July 15, 2026, 6:02pm

Thanks for looking into this, @ericteubert.

The weird thing is, that it seems to happen with all podcast clients I tried on iOS. I tested Castro, Pocket Casts, Podcat and Overcast. Neither of them can download an episode. I don’t have an Android device to test it myself. But from the few people we know, there doesn’t seem to be a problem on this platform.

Admittedly, Freak Show (which I guess also uses Podlove) does work.

By now, I would bet on a misconfiguration on our end. But nothing changed for Textlastig in years (not even new episodes). I just kept updating Podlove Publisher (which never caused any issues). Any wild guesses as to what setting might cause this, given the limited info?

ericteubert · July 17, 2026, 11:32am

Castro is the most helpful one because it at least returns the HTTP error code: HTTP/2 421 Misdirected Request

That’s beyond my expertise, I’ll leave you with the LLM analysis in case it helps:

Both hostnames resolve to the same IP:
textlastig.com        → 85.13.164.195
media.textlastig.com  → 85.13.164.195
The download redirects between them:
textlastig.com/podlove/... → media.textlastig.com/tl254_nlp.mp3
They use separate TLS virtual hosts/certificates. I reproduced the exact error by requesting the media hostname through a TLS connection established for the main hostname:
HTTP/2 421 Misdirected Request
Server: Apache
Castro is therefore likely reusing the original HTTP/2 connection after the redirect. Apache sees TLS/SNI for textlastig.com but Host: media.textlastig.com and rejects it. Browsers either open a fresh connection or automatically retry after 421, which explains why they work.

Apache documents precisely this behavior for HTTP/2 virtual hosts with incompatible TLS configurations. Apache mod_http2 documentation

Recommended fixes, in order:

Avoid the cross-host redirect. Serve the enclosure from one hostname, or make the feed point directly to https://media.textlastig.com/tl254_nlp.mp3. This is the safest and quickest confirmation/fix.

Alternatively, give both virtual hosts one certificate containing both names and ensure their TLS settings are identical.

Disabling HTTP/2 may work around connection coalescing, but is less desirable.

Do not weaken Apache’s SNI security policy to insecure; Apache warns that this can introduce a security vulnerability.