[PHP] Beveiligde (?) website openen

[corani]

Ik zit met een probleem. Ik wil met behulp van PHP een bepaalde webpagina inlezen. Als ik deze pagina open met Internet Explorer, gaat het gewoon goed. Maar als ik hem met PHP open, naar de output echo, en bekijk met dezelfde Internet Explorer, zie ik het grootste deel van de pagina, maar net een essentieel stukje informatie niet.

Normaal gesproken wordt deze informatie gewoon inline in de html getoond (dus geen grappen met javascript of iframes of wat dan ook) echter als ik hem met PHP binnenhaal is deze informatie verdwenen.

Ik heb het volgende geprobeerd:

PHP:

$data = file("http://www.site.com/pagina.php?id=1");

Geeft netjes de pagina terug - zonder de informatie die ik wil -

PHP:

if ($fp)
{
    $fp = fsockopen("www.site.com", 80, $errnum, $errstr);
    $header = "GET /pagina.php?id=1 HTTP/1.1\r\n
        Host: www.site.com\r\nConnection: close\r\n\r\n";
    fputs ($fp, $header);
    while (!feof($fp))
    {
        echo fgets ($fp,128);
    }
    fclose ($fp);
}

idem

PHP:

$ch = curl_init();
$curl_setopt($ch, CURLOPT_URL,"http://www.site.com/pagina.php?id=1");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_PROXY, "localhost:3128");
curl_setopt($ch, CURLOPT_USERAGENT,
    "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)");
curl_setopt($ch, CURLOPT_REFERER, "http://www.site.com");
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
$data=curl_exec ($ch);
curl_close ($ch);

Volgens mij moet dit zo wel lijken op wat Internet Explorer doet (inclusief gebruik maken van m'n proxy) maar het werkt dus niet.

Ik heb het vervolgens geprobeerd met lynx, wget en commandline curl, maar telkens hetzelfde verhaal.

Iemand enig idee??

[ Voor 11% gewijzigd door corani op 23-03-2004 14:49 . Reden: sorry, layout gefixed ]

[Reptile209]

Kan het niet zo zijn dat een deel van de pagina in een tweede TCP-pakketje verstuurd wordt? Als het goed is, moet je daarvoor (in het eerste pakket dat je al wel krijgt) op zoek gaan naar de Content-length en de Chuncked headers. Je moet net zo lang pakketjes inlezen, totdat er een time-out is of je Content-length aan bytes binnen hebt.
Zoek anders eens naar de RFC voor HTTP, daar staan ook de juiste header-namen die ik bedoel in.

Ohja, je zou dit kunnen testen door een pagina van bijvoorbeeld < 1 kB binnen te halen. Zet ff een testfile online en haal die binnen.

[curry684]

corani schreef op 23 maart 2004 @ 14:44:
Ik heb het vervolgens geprobeerd met lynx, wget en commandline curl, maar telkens hetzelfde verhaal.

Je bedoelt hiermee dus dat die allemaal dat ene stukje informatie missen dat IE wel geeft?

Zo ja zou ik toch eens met Ethereal of een andere packetsniffer gaan kijken wat IE exact verstuurt richting die site...

[corani]

Reptile209 schreef op 23 maart 2004 @ 14:48:
Kan het niet zo zijn dat een deel van de pagina in een tweede TCP-pakketje verstuurd wordt? Als het goed is, moet je daarvoor (in het eerste pakket dat je al wel krijgt) op zoek gaan naar de Content-length en de Chuncked headers. Je moet net zo lang pakketjes inlezen, totdat er een time-out is of je Content-length aan bytes binnen hebt.

Dit is de header die ik terugkrijg als ik het fopen verhaal doe:

code:

HTTP/1.1 200 OK
Date: Tue, 23 Mar 2004 13:36:19 GMT
Server: Apache/1.3.28 (Unix) mod_ssl/2.8.15 OpenSSL/0.9.7c
    FrontPage/5.0.2.2634 PHP/4.3.4
X-Powered-By: PHP/4.3.4
Set-Cookie: visa=1; expires=Mon, 17-Jan-2005 13:36:19 GMT
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html

Maar zou hij dat nu niet al allemaal binnenhalen?

In ieder geval zouden lynx/wget/commandline curl dat moeten doen, toch?

curry684 schreef op 23 maart 2004 @ 14:49:
[...]

Je bedoelt hiermee dus dat die allemaal dat ene stukje informatie missen dat IE wel geeft?

Zo ja zou ik toch eens met Ethereal of een andere packetsniffer gaan kijken wat IE exact verstuurt richting die site...

Inderdaad, met lynx/wget/commandline-curl krijg ik allemaal niet die ene regel binnen. Ik zal eens op zoek gaan met een sniffer...

[ Voor 21% gewijzigd door corani op 23-03-2004 14:53 . Reden: reactie op curry684, bah weer die layout ]

[curry684]

corani schreef op 23 maart 2004 @ 14:51:
[...]
Inderdaad, met lynx/wget/commandline-curl krijg ik allemaal niet die ene regel binnen. Ik zal eens op zoek gaan met een sniffer...

Mjah die return headers zien er heel authentiek uit, dus ik kan me eigenlijk alleen voorstellen dat er een of andere ranzige filtering op zit op een of andere not-required header die IE verstuurt. Wat doet Firefox eigenlijk?

[Reptile209]

Als ik de betreffende RFC (hoofdstuk 3.6) even snel doorblader, dan moet je met dit pakketje 1) alle data hebben, of 2) mist er een chunk-size regel.
Blijf bij het inlezen van data eens doorlezen tot aan een time-out (server verbreekt de verbinding wel). Volgens mij moet je dan toch nog meer binnenkrijgen. Blijft dan wel de vraag wat die EOF daar doet...

[corani]

curry684 schreef op 23 maart 2004 @ 14:58:
[...]

Mjah die return headers zien er heel authentiek uit, dus ik kan me eigenlijk alleen voorstellen dat er een of andere ranzige filtering op zit op een of andere not-required header die IE verstuurt. Wat doet Firefox eigenlijk?

Okay mensen, met ethereal had ik het vrij snel gevonden. Ik was een cookie vergeten mee te sturen... (schaam )

[curry684]

corani schreef op 23 maart 2004 @ 15:13:
[...]


Okay mensen, met ethereal had ik het vrij snel gevonden. Ik was een cookie vergeten mee te sturen... (schaam )

LOL

Blijft vreemd dan wel dat Lynx die dan niet pikt, die ondersteunt toch cookies afaik...

[corani]

curry684 schreef op 23 maart 2004 @ 15:29:
[...]

LOL

Blijft vreemd dan wel dat Lynx die dan niet pikt, die ondersteunt toch cookies afaik...

Ja, das waar... in lynx bood die site ook maar 1 cookie aan. Blijkbaar heeft IE eerder al een keer een cookie gekregen, die hij nodig had.. Ik heb het even gecontroleerd, en die cookie komt van het forum van die site vandaan. De pagina die ik nodig had staat daar echter geheel los van, dus ik vind het vreemd dat ze daarop checken...