HotTopic XML kapot? - kees

[crisp]

Ik krijg zowel thuis als hier op mijn werk geen XML feed meer van deze link.
Volgens mijn GoT Tracker is dat vanaf ongeveer kwart over 1 afgelopen nacht het geval. Is 'ie uitgezet?

[chem]

Ik zie een recente feed daar staan ?

[crisp]

chem schreef op 01 May 2003 @ 10:52:
Ik zie een recente feed daar staan ?

Ik krijg een leeg scherm...

[chem]

<?xml version="1.0" encoding="ISO-8859-1" ?>
<activetopics>
<topic>
<id>747575</id>
<titel>Digitale camera foto&#039;s deel 16</titel>
<forum>33</forum>
<forumafkorting>GT</forumafkorting>

<startts>1051384175</startts>
<lastts>1051779514</lastts>
<topicstarter>MatthijsN</topicstarter>
<starterid>35202</starterid>
<replies>230</replies>
<last_replier>Devster</last_replier>

<replierid>24067</replierid>
<messageid></messageid>
</topic>
etc...

[Nazgul]

Ook ik zie niets meer dan een leeg scherm.

edit:
Thuis @ IE 6 doet hij het wel

[ Voor 35% gewijzigd door Nazgul op 01-05-2003 23:37 . Reden: Thuis getest ]

[crisp]

Mmmz, ff een php file op mijn webserver gezet:

PHP:

<?php

$fp = fopen('http://gathering.tweakers.net/forum/hottopic_xml', 'r');
fpassthru($fp);
fclose($fp);

?>

hier krijg ik nu wel een feed van, het lijkt dus locatie-afhankelijk te zijn...

[chem]

Dan is het min of meer out of my hands
ik pass deze even naar een admin.

[crisp]

extra info: cache legen, cookies trashen maakt geen verschil.
Misschien even nagaan of er wat is gewijzigd vannacht? extra headers ofzo die nu roet in het eten gooien? (mijn scriptje stript natuurlijk additionele headers nu)

[chem]

De headers:

code:

HTTP/1.x 200 OK
Date: Thu, 01 May 2003 09:20:29 GMT
Server: Apache/1.3.27 (Unix) PHP/4.3.1 mod_gzip/1.3.19.1a
X-Served-By: Acidalia, Acidalia, Acidalia, Acidalia
X-Powered-By: PHP/4.3.1
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified: Thu, 01 May 2003 09:20:29 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Encoding: gzip
Connection: close
Transfer-Encoding: chunked
Content-Type: text/xml;charset=iso-8859-15

[Kees]

Er is idd een aditionele header (X-Served-By) verder draaien de servers php-4.3.1 sinds vannacht.

Maar ik kan niet bedenken waarom ik bij elke request een page krijg, en jij niets
ligt het aan je browser?

[crisp]

Kees schreef op 01 May 2003 @ 11:32:
Er is idd een aditionele header (X-Served-By) verder draaien de servers php-4.3.1 sinds vannacht.

Maar ik kan niet bedenken waarom ik bij elke request een page krijg, en jij niets
ligt het aan je browser?

Hier: win95 met IE5.5
Thuis: win2k met IE6

Ik meen dat ik thuis wel in mijn browser een feed kreeg, maar mijn Tracker weigerde de XML te parsen, ik had echter geen tijd daar verder naar te kijken. Hier krijg ik dus een scherm met een leeg HTML document.
Mijn webserver draait ook PHP4.3.1, ik zal eens kijken wat het effect van de X-Served-By header is in mijn passthru scriptje, en of dat problemen oplevert mbt parsen van de XML.

Edit: mmz, ik heb hier gewoon niet de beschikking over de juiste tools en mogelijkheden om dit te analyseren, moet ik vanavond thuis doen dus...

[ Voor 10% gewijzigd door crisp op 01-05-2003 12:25 ]

[MAZZA]

Bij mij:
Win95 IE5 --> GEEN output
Win95 Mozilla --> WEL output
Win95 Opera --> WEL output

Beetje browserafhankelijk blijkbaar. De win95 machine is 1 en dezelfde pc.

[ Voor 13% gewijzigd door MAZZA op 01-05-2003 14:33 ]

[crisp]

MAZZA schreef op 01 May 2003 @ 14:32:
Bij mij:
Win95 IE5 --> GEEN output
Win95 Mozilla --> WEL output
Win95 Opera --> WEL output

Beetje browserafhankelijk blijkbaar. De win95 machine is 1 en dezelfde pc.

Ik heb ook al zwaar het vermoeden dat het MSXMLx.DomDocument ActiveX object wat moeite heeft met de XML feed, en dat het probleem dus IE-related is...

Kees: was deze feed voorheen ook al ge-gzipped?

[ Voor 8% gewijzigd door crisp op 01-05-2003 14:45 ]

[crisp]

Kees schreef op 01 May 2003 @ 11:32:
Er is idd een aditionele header (X-Served-By) verder draaien de servers php-4.3.1 sinds vannacht.

Maar ik kan niet bedenken waarom ik bij elke request een page krijg, en jij niets
ligt het aan je browser?

Ik krijg hier (thuis) dus idd wel een page, maar de IE MSXML ActiveX control weigert de XML te parsen met als foutmelding:

"Only one top level element is allowed in an XML document"

Het stomme is dat als ik 'm dus passthru doe via mijn webserver het wel goed gaat. Het moet dus haast wel aan de headers liggen of de gzip compressie.
Als ik echter de genoemde headers meestuur via mijn webserver gaat het vreemd genoeg ook goed.
De Mozilla XML parser doet het ook goed, dus het zal wel weer een IE-nuk zijn.

Die activeX control kan ik verder helaas niet debuggen (heerlijk closed-source), en afvragingen op het xmlDoc object wat ik creeer leveren ook alleen foutmeldingen op.

Ik denk dat het lastig gaat worden de precieze oorzaak te vinden, vooralsnog kan ik de GoT Tracker nog wel gebruiken via mijn PHP scriptje (alleen ff uitvogelen hoe ik de ReactID kan meesturen zodat ik ook topics in niet-publieke fora te zien krijg), maar ik vrees dat voor anderen deze XML feed voor windows-based applicaties niet bruikbaar meer is...

[Whieee]

hier:
WinXP IE6 : niks
WinXP Netscape 7 : niks

[Verwijderd]

windows xp ie6 sp1 werkt prima

[Kees]

hmm, ik ben dan wel erg benieuwd wat php 4.3.1 precies veranderd aan de XML..
Overigens was hij al een tijdje gegziped, ongeveer een half jaar denk ik.

Het enige wat vannacht veranderd is is de PHP versie en de extra header. De browser moet die extra header gewoon negeren (X-headers zoals de X-Powered-by van php moet hij niets mee doen en gewoon negeren). Blijft dus de PHP versie over, toch eens snuffelen in de changelogs.

[crisp]

Kees schreef op 01 May 2003 @ 19:46:
hmm, ik ben dan wel erg benieuwd wat php 4.3.1 precies veranderd aan de XML..
Overigens was hij al een tijdje gegziped, ongeveer een half jaar denk ik.

Het enige wat vannacht veranderd is is de PHP versie en de extra header. De browser moet die extra header gewoon negeren (X-headers zoals de X-Powered-by van php moet hij niets mee doen en gewoon negeren). Blijft dus de PHP versie over, toch eens snuffelen in de changelogs.

De XML is het denk ook niet, volgens mij is het gewoon weer een of andere IE-nuk dat 'ie door de combinatie van headers over de zeik gaat of zo. De Mozilla built-in scriptable parser (wat is het, XUL ofzo?) doet het ook gewoon prima.
After all is het enkel wat headers en een zut platte text, dat het ge-gzipped is moet volgens mij ook niet uitmaken, dat wordt voor zover ik weet al deflated voordat het verwerkt wordt.
Kan iemand even testen of HotTopic nog werkt?

[crisp]

Even een packet sniffer tussen gezet en gekeken wat ik terugkreeg van de server na de headers:

code:

<br />
<b>Warning</b>:  parse_url(file://F:\gottracker\source\tracker.html)
 [<a href='http://www.php.net/function.parse-url'>function.parse-url</a>]:
 Unable to parse url in <b>/mnt/web/react/got/react/global/non-
www/actionclasses/hottopic_xml.classes.inc.php</b> on line <b>64</b><br />
<?xml version="1.0" encoding="ISO-8859-1" ?>
<activetopics>
    <topic>
        <id>749858</id>
        <titel>Het (grote) &amp;quot;wie gaan er naar de matrix 2&amp;quot; topique</titel>
        <forum>31</forum>
// etcetera

de "file://F:\gottracker\source\tracker.html" is de referrer die meegegeven wordt in de GET request door de GoT Tracker.
Blijkbaar is er iets gewijzigd in PHP4.3.1 waardoor parse_url() daar zijn nek over breekt

(even wat enters toegevoegd in de foutmelding, die staat normaal op 1 lijn)

[Kees]

There has been some breakage it seems between 4.2.3 and 4.3...

print_r(parse_url("http://localhost?key3=value3"));

...gives...

Array
(
[scheme] => http
[host] => localhost?key3=value3
)

...in 4.3 whereas in 4.2.3 it parses with the query in the correct place. I guess it depends on what you mean by a fragment. This is on Linux.

Hmm, die functie hebben ze dus kapot gemaakt...
http://bugs.php.net/bug.php?id=22423

[ Voor 5% gewijzigd door Kees op 02-05-2003 00:35 ]

[crisp]

Kees schreef op 01 May 2003 @ 23:56:
[...]

Hmm, die functie hebben ze dus kapot gemaakt...

Je genoemde voorbeeld levert geen warning op, alleen een verkeerde break-up.
Ik denk eerder dat 'ie zijn nek breekt over de 2e dubbele punt in file://F:/etc
Daardoor confirmeerd een link naar een lokale file niet naar een URL en krijg je een warning.
Misschien heel quick en dirty een @ ervoor zetten? Ik weet niet waar het script de referrer voor nodig heeft, maar vaak genoeg zal er ook geen referrer zijn, dus ik neem aan dat het niet van curciaal belang is...

Edit: deze is meer van toepassing denk ik: http://bugs.php.net/bug.php?id=22423

Edit2: apart bugreport aangemaakt omdat het in dit geval om een warning-melding gaat (bovengenoemd geval geeft geen warning): http://bugs.php.net/bug.php?id=23445

[ Voor 26% gewijzigd door crisp op 02-05-2003 00:42 ]

[crisp]

Kees:
(oftewel: het werkt weer!)

Edit: gezien de reactie op mijn bugreport zou het in een later CVS gefixed moeten zijn...

[ Voor 63% gewijzigd door crisp op 02-05-2003 02:37 ]

[MAZZA]

Hier werkt het nog steeds niet Zelfde config. Hij blijft hier constant laden...

[crisp]

MAZZA schreef op 02 mei 2003 @ 10:36:
Hier werkt het nog steeds niet Zelfde config. Hij blijft hier constant laden...

Zal wel iets van IE5 zijn. In elk geval kan de GoT Tracker 'm wel goed laden en verwerken in IE5.5 hier (de feed is ook niet bedoeld om zo in je browser te bekijken).

[Kees]

ok, opgelost dus