[php] fsockopen problemen. timeout & HTTP 302 zonder locatie

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • marty
  • Registratie: Augustus 2002
  • Laatst online: 27-03-2023
Ik ben wat aan het stoeien met fsockopen en posten van formulieren over een SSL verbinding.

Met m'n php script moet ik de volgende route doorlopen (alles gaat via https)

1. opvragen beginpagina: cookie afvangen
2. login-pagina opvragen (met dit cookie): nog een cookie afvangen
3. login-formulier posten: nog 3 cookies afvangen
4. ander formulier (achter de login) posten

Stap en 1 en 2 gaan dus via GET, deze stappen gaan goed. Controles leren dat ik de juiste cookies afvang en dat ik deze ook succesvol weer mee stuur.
Als ik vervolgens bij stap 3 het login-formulier post dan gaat het fout.

Dit is de code waar ik de data mee opvraag:
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
if ($fp = fsockopen("ssl://".$host, 443, $errno, $errstr, 15))
{
    fputs($fp, $post);

    $data = "";
    while(!feof($fp))
    {
        $data .= fread($fp, 4096);
    }
    fclose($fp);

    return $data;
}

Dit blijft oneindig lang laden. De verbinding (fsockopen) wordt wel gemaakt, maar het blijkt dat ie fout loopt op het while-loopje. Als ik dit doe

PHP:
1
2
3
4
5
6
7
8
if ($fp = fsockopen("ssl://".$host, 443, $errno, $errstr, 15))
{
    fputs($fp, $post);
    $data = fread($fp, 1000000);
    fclose($fp);

    return $data;
}


Gaat het namelijk wel goed. Ik krijg dan echter als output:

code:
1
HTTP/1.1 302 Found


Dat is alles :S
Ik ben vervolgens die while loop nog eens gaan aanpassen en heb 4096 in (uiteindelijk) 2 veranderd (kon me voorstellen dat ie zich daar in verslikte ofzo), maar nog steeds blijft ie eindeloos laden.

Ik weet dat die 302 betekent dat ik doorgerout wordt naar een andere pagina (en dit klopt ook), maar de Locatie ontbreekt dus. Ik heb voor de gein vervolgens geprobeerd via een get-request een pagina achter de login op te vragen en dan krijg ik ook zo'n 302, maar dan wel uitgebreid met locatie (van de login-pagina uiteraard :))

Ik loop nu al een paar uur te klooien en te lezen op internet, maar ik kom er niet uit wat er fout gaat.
- hoe kan het komen dat die while oneindig lang blijft laden?
- hoe komt het dat die andere constructie alleen een 302 oplevert zonder verdere informatie?

Het één zal vast met het ander te maken hebben...

p.s. alle variabelen in het voorbeeld hebben de juiste waardes, dit heb ik met echo's gecontroleerd. De hele routine heb ik ook op een eigengemaakt login-systeem getest, die niet via https verliep en daar ging het prima. Daar kan het dus niet aan liggen.

Acties:
  • 0 Henk 'm!

  • MTWZZ
  • Registratie: Mei 2000
  • Laatst online: 13-08-2021

MTWZZ

One life, live it!

Als je de mogelijkheid hebt om dit te testen zonder SSL kun je proberen met ethereal de verbinding te sniffen. Het kan geloof ik ook wel met een tool die ssl decrypt maar dat is nogal een gehannes.

Nu met Land Rover Series 3 en Defender 90


Acties:
  • 0 Henk 'm!

  • marty
  • Registratie: Augustus 2002
  • Laatst online: 27-03-2023
nee die mogelijkheid heb ik helaas niet. die niet-SSL opstelling had ik gewoon zelf gemaakt op m'n eigen servertje (die weer niet over een ssl mogelijkheid beschikt)

Nog wat extra info trouwens:
Ik draai zelf PHP 4.3.10 met OpenSSL support Enabled en (helaas) geen CURL

Acties:
  • 0 Henk 'm!

  • GlowMouse
  • Registratie: November 2002
  • Niet online
Dat de while-loop nooit stop heeft misschien met Keep-Alive te maken, dat de server de verbinding dus een tijd openhoudt. Een en ander staat hier uitgelegd, ook welke header je moet toevoegen om geen keep-alive te gebruiken onder HTTP/1.1.

Dat fread alleen een header laat zien, is eenvoudig te verklaren. fread($fp, 1000000); leest het eerste pakketje uit (mits niet groter dan 1000000 bytes). Nog een fread actie zou het tweede pakketje uitlezen waar weer meer informatie instaat.

[ Voor 36% gewijzigd door GlowMouse op 20-07-2006 16:31 . Reden: link toegevoegd ]


Acties:
  • 0 Henk 'm!

  • marty
  • Registratie: Augustus 2002
  • Laatst online: 27-03-2023
GlowMouse schreef op donderdag 20 juli 2006 @ 16:20:
Dat de while-loop nooit stop heeft misschien met Keep-Alive te maken, dat de server de verbinding dus een tijd openhoudt.
nee, Keep-Alive had ik al op Close gezet omdat het iedere keer zo onwijs lang duurde.
Dat fread alleen een header laat zien, is eenvoudig te verklaren. fread($fp, 1000000); leest het eerste pakketje uit (mits niet groter dan 1000000 bytes). Nog een fread actie zou het tweede pakketje uitlezen waar weer meer informatie instaat.
Ah, ok werkt dat zo.
Dit heeft me al een heel eind verder geholpen!
Ik heb nu een loopje gemaakt die 10x een pakketje uitleest en ben nu achter de locatie gekomen.
En ik krijg nu ook een error te zien:
code:
1
Warning: fread(): SSL: fatal protocol error in /var/www/virtual/seniorgroep.nl/htdocs/test/functions.php on line 83


dat heeft ongetwijfeld met dat oneindig laden te maken. zal eens op gaan zoeken hoe dat komt

Acties:
  • 0 Henk 'm!

  • GlowMouse
  • Registratie: November 2002
  • Niet online
marty schreef op donderdag 20 juli 2006 @ 16:34:
[...]
nee, Keep-Alive had ik al op Close gezet omdat het iedere keer zo onwijs lang duurde.
Het is Connection dat je op Close moet zetten.

Acties:
  • 0 Henk 'm!

  • marty
  • Registratie: Augustus 2002
  • Laatst online: 27-03-2023
GlowMouse schreef op donderdag 20 juli 2006 @ 16:41:
[...]

Het is Connection dat je op Close moet zetten.
hehe, weet ik ;)
ik bedoelde het als: de Keep-Alive waarde voor de connectie had ik al op Close gezet (nadat ik was gaan zoeken waarom het zo rete-traag ging)

btw, die error komt hierdoor:
http://www.zend.com/manual/function.fopen.php

Warning

When using SSL, Microsoft IIS will violate the protocol by closing the connection without sending a close_notify indicator. PHP will report this as "SSL: Fatal Protocol Error" when you reach the end of the data. To workaround this, you should lower your error_reporting level not to include warnings. PHP 4.3.7 and higher can detect buggy IIS server software when you open the stream using the https:// wrapper and will suppress the warning for you. If you are using fsockopen() to create an ssl:// socket, you are responsible for detecting and suppressing the warning yourself.

[ Voor 52% gewijzigd door marty op 20-07-2006 16:50 ]

Pagina: 1