Momentan laedt mein Podcatcher (gPodder) den GLaubenssache-Feed nicht mehr. Dies scheint daran zu liegen, dass der Server (bzw. die darauf laufenden Skripte) ein paar HTTP-Header ungueltig setzen bzw. der uebertragene Inhalt nicht zu den gesetzen HTTP-Headern passen. Dies wird auch vom W3C-Feed-Validator unter https://validator.w3.org/feed/check.cgi?url=http%3A%2F%2Fglaubenssache.info%2Ffeed%2Fmp3%2F bestaetigt
Not a gzipped file (Server response declares Content-Encoding: gzip; misconfigured server?) [help]
Schauen wir uns kurz an was gesendet wird:
$ curl --compressed -4 -v http://glaubenssache.info/feed/mp3/ -o feed.xml
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 173.236.152.173...
* Connected to glaubenssache.info (173.236.152.173) port 80 (#0)
> GET /feed/mp3/ HTTP/1.1
> Host: glaubenssache.info
> User-Agent: curl/7.42.1
> Accept: */*
> Accept-Encoding: deflate, gzip
>
< HTTP/1.1 200 OK
< Date: Sat, 16 May 2015 16:21:24 GMT
< Server: Apache
< X-Pingback: http://glaubenssache.info/page/xmlrpc.php
< ETag: "406802d49a0514e1b5df4d5ced75c9df"
< Content-Encoding: gzip
< Vary: Accept-Encoding
< Set-Cookie: wfvt_871969492=55576e84d482b; expires=Sat, 16-May-2015 16:51:24 GMT; path=/; httponly
< Last-Modified: Sat, 16 May 2015 09:36:56 GMT
< Transfer-Encoding: chunked
< Content-Type: text/xml; charset=UTF-8
<
{ [1024 bytes data]
100 4298 0 4298 0 0 4883 0 --:--:-- --:--:-- --:--:-- 4884
* Connection #0 to host glaubenssache.info left intact
Ok, auf den ersten Blick sieht das doch ganz ok aus.... aber sowohl W3C als auch mein gPodder moegen den Inhalt nicht. Also koennte bei dem GZIP-komprimierten Inhalt irgendwas kaputt sein, dass curl gekonnt zu ignorieren weiss. Also laden wir kurz das Ganze runter und lassen curl die Daten nicht automatisch dekomprimieren.
$ curl --header "Accept-Encoding: deflate, gzip" -4 -v http://glaubenssache.info/feed/mp3/ -o feed.xml.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 173.236.152.173...
* Connected to glaubenssache.info (173.236.152.173) port 80 (#0)
> GET /feed/mp3/ HTTP/1.1
> Host: glaubenssache.info
> User-Agent: curl/7.42.1
> Accept: */*
> Accept-Encoding: deflate, gzip
>
< HTTP/1.1 200 OK
< Date: Sat, 16 May 2015 16:27:28 GMT
< Server: Apache
< X-Pingback: http://glaubenssache.info/page/xmlrpc.php
< ETag: "406802d49a0514e1b5df4d5ced75c9df"
< Content-Encoding: gzip
< Vary: Accept-Encoding
< Set-Cookie: wfvt_871969492=55576ff055fb7; expires=Sat, 16-May-2015 16:57:28 GMT; path=/; httponly
< Last-Modified: Sat, 16 May 2015 09:36:56 GMT
< Transfer-Encoding: chunked
< Content-Type: text/xml; charset=UTF-8
<
{ [1024 bytes data]
100 4298 0 4298 0 0 5260 0 --:--:-- --:--:-- --:--:-- 5267
* Connection #0 to host glaubenssache.info left intact
Schauen wir uns mal die empfangen Daten an:
$ file feed.xml.gz
feed.xml.gz: gzip compressed data, from Unix
$ zcat feed.xml.gz > /dev/null
gzip: feed.xml.gz: decompression OK, trailing garbage ignored
Aha, es ist also nicht korrekt per GZIP-komprimiert, da noch extra Daten am Ende der Datei gefunden wurden. Schauen wir mal was da steht:
$ hexdump -C feed.xml.gz|tail -n 5
00001090 e3 b1 71 37 a0 8f 5a e5 df 5d ab c0 bd ea 1f 21 |..q7..Z..].....!|
000010a0 1b e2 3f ca 35 da fa 27 d7 a8 cd f8 f5 4d 00 00 |..?.5..'.....M..|
000010b0 3c 21 2d 2d 20 68 74 6d 6c 20 69 73 20 63 6f 72 |<!-- html is cor|
000010c0 72 75 70 74 65 64 20 2d 2d 3e |rupted -->|
000010ca
Ok, nach den Binaerdaten des GZIP-komprimierten Feeds steht also noch "". Das gehoert da sicherlich nicht hin. Es ist nicht unbedingt einfach zu raten was der Grund ist, aber ich versuch es trotzdem (und liege daher moeglichweise falsch). Es wird wahrscheinlich ein Wordpress-Caching-Plugin eingesetzt, das Probleme hat, wenn die uebertragenen Daten nicht unkomprimierte HTML/XML-Daten sind, sondern von Wordpress bzw. einem anderen Plugin vorher komprimiert wurden. Zumindesten kann ich einen passenden String im Quelltext dieses Plugins finden: https://github.com/wp-plugins/wp-fastest-cache/blob/f1d6dc04dec293e2257625072a544d36c06fac06/inc/cache.php#L161
Was koennte man dagegen machen? Das ist eher schwer fuer mich zu beantworten, da ich das Plugin nicht kenne. Ein paar andere Strings im Quelltext lassen aber vermuten, dass man andere Plugins bzw. Wordpress so anpassen muss, dass kein vorher ausgefuehrtes Plugin die Daten komprimieren wuerde. https://github.com/wp-plugins/wp-fastest-cache/blob/f1d6dc04dec293e2257625072a544d36c06fac06/inc/admin.php#L361
Uebrigens benutze ich hier IPv4, da der Server bei IPv6-Verbindungen scheinbar nur einen Zugriff zulaesst und danach weitere Verbindungen sperrt. Das ist besonders unguenstig, wenn man noch die alte URL hat und dann per HTTP 301 weitergeleitet wird. Dann wird natuerlich die zweiter Verbindung blockiert und man muss warten bis der Verbindungsversuch vom Client als misslungen erkannt wird.
Schöne Analyse :)
Ich würde vorschlagen, ein anderes Caching Plugin zu benutzt, das sich zu benehmen weiß.