Opened by pq at 2011-08-29 14:46
User since
2003-08-04
12208 Artikel
Admin1
![[Homepage]](/battie/theme/default/homepage.gif)
2003-08-04
12208 Artikel
Admin1
hi,
ich habe hier ein seltsames phänomen mit dem newsfeed von golem.
die eigentliche url lautet: http://rss.golem.de/rss.php?feed=RSS1.0
diese url leitet aber zu http://golem.de.dynamic.feedsportal.com/pf/578068/... weiter, da golem seinen feed dort hosten lässt.
soweit, so gut.
in firefox, mit GET und lynx kriege ich da auch den feed als xml geliefert.
in opera leitet diese url aber auf https://golem.de.dynamic.feedsportal.com/pf/578068... weiter, was ein problem ist, da das zertifikat nicht für feedsportal.com ausgestellt ist.
nun bin ich der sache auf den grund gegangen und habe mittels telnet nachvollzogen, dass es die request-header sind, also kein bug in opera.
wenn ich das ausführe, bekomme ich verschlüsselte daten geliefert.
wenn ich aber alle header nach dem 'Host'-Header weglasse, dann kommt unverschlüsseltes xml.
mit wireshark sehe ich auch einen Location-Header, der auf https zeigt, wenn ich das in Opera aufrufe.
irgendwas an den headern ist also speziell, so dass feedsportal.com auf https weiterleitet.
Ich habe schon Golem angeschrieben, aber die fühlen sich dafür nicht verantwortlich, da das ja nicht ihre Domain ist.
kann jemand das ergebnis des telnet-requests bestätigen?
edit: der entscheidende header ist Accept-Encoding:
liefert ssl. ohne Accept-Encoding kommt das unverschlüsselte xml.
Last edited: 2011-08-29 15:00:21 +0200 (CEST)
ich habe hier ein seltsames phänomen mit dem newsfeed von golem.
die eigentliche url lautet: http://rss.golem.de/rss.php?feed=RSS1.0
diese url leitet aber zu http://golem.de.dynamic.feedsportal.com/pf/578068/... weiter, da golem seinen feed dort hosten lässt.
soweit, so gut.
in firefox, mit GET und lynx kriege ich da auch den feed als xml geliefert.
in opera leitet diese url aber auf https://golem.de.dynamic.feedsportal.com/pf/578068... weiter, was ein problem ist, da das zertifikat nicht für feedsportal.com ausgestellt ist.
nun bin ich der sache auf den grund gegangen und habe mittels telnet nachvollzogen, dass es die request-header sind, also kein bug in opera.
Code: (dl
)
1
2
3
4
5
6
7
8
9
$ telnet golem.de.dynamic.feedsportal.com 80
GET /pf/578068/http://rss.golem.de/rss.php?feed=RSS1.0 HTTP/1.1
User-Agent: Opera/9.80 (X11; Linux i686; U; de) Presto/2.9.168 Version/11.50
Host: golem.de.dynamic.feedsportal.com
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: de-DE,de;q=0.9,en;q=0.8
Accept-Encoding: gzip, deflate
Cache-Control: no-cache
Connection: Keep-Alive
wenn ich das ausführe, bekomme ich verschlüsselte daten geliefert.
wenn ich aber alle header nach dem 'Host'-Header weglasse, dann kommt unverschlüsseltes xml.
mit wireshark sehe ich auch einen Location-Header, der auf https zeigt, wenn ich das in Opera aufrufe.
irgendwas an den headern ist also speziell, so dass feedsportal.com auf https weiterleitet.
Ich habe schon Golem angeschrieben, aber die fühlen sich dafür nicht verantwortlich, da das ja nicht ihre Domain ist.
kann jemand das ergebnis des telnet-requests bestätigen?
edit: der entscheidende header ist Accept-Encoding:
Code: (dl
)
1
2
3
4
$ telnet golem.de.dynamic.feedsportal.com 80 >telnet_opera12
GET /pf/578068/http://rss.golem.de/rss.php?feed=RSS1.0 HTTP/1.1
Host: golem.de.dynamic.feedsportal.com
Accept-Encoding: gzip, deflate
liefert ssl. ohne Accept-Encoding kommt das unverschlüsselte xml.
Last edited: 2011-08-29 15:00:21 +0200 (CEST)
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
lesen:
Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
lesen:
Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem