[PHP] fread stopt na bepaald aantal bytes

[BramT]

Volgende probleem: deze code

PHP:

    $pagedata = fopen($rippage,'r'); // open file, read-only
    if (!$pagedata) die("unable to get remote file... aborting.");  // indien fout...
    $htmldata = fread($pagedata,10*1024); // lees maximaal 10kb aan data (bug op 2687???)
    fclose($pagedata);
    return $htmldata;

leest alleen de eerste 2687 bytes van de (remote) pagina die ik heb opgegeven. Misschien is dit nummer toeval, misschien niet.

Iemand meer ervaring met fread? Op http://nl.php.net/fread geven ze geen informatie over dit probleem...

[Verwijderd]

werkt wel bij mij, dus misschien is het een ander stukje code dat de fout in gaat...

[ Voor 174% gewijzigd door Verwijderd op 15-07-2003 12:38 ]

[Bosmonster]

Move W&G -> P&W

[creative8500]

a) verkeerd forum WG -> PW
b) de juiste behandeling voor jouw probleem is de volgende:

PHP:

// 1 - zet de file resource handler in een variabele
$file = fopen($page,'r');

// 2 - lees met fread een groot aantal bytes van de resource
$content = fread($file,9999999);

// of nog beter
if(fopen($file = fopen($page,'r'))
{
   fread($file,9999999);
}
else
{
    // error handling hier . . .
}

[ edit 1 ]
Andere mogelijke oplossing:

PHP:

// bij gebruik van PHP 4.3.0 (of hoger)
file_get_contents($page); // geeft het bestand terug in een string

// bij gebruik van een eerdere versie
file($page); // geeft het bestand terug in een array

[ Voor 37% gewijzigd door creative8500 op 15-07-2003 12:47 . Reden: 1) aanvullende informatie 2) verkeerde quote ]

[LuCarD]

It is a feature...

Note: When reading from network streams or pipes, such as those returned when reading remote files or from popen() and proc_open(), reading will stop after a packet is available. This means that you should collect the data together in chunks as shown in the example below.

maw 2687 bytes is het eerste pakketje.

Oplossing word ook gegeven.

PHP:

$handle = fopen ("http://www.php.net/", "rb");
$contents = "";
do {
    $data = fread ($handle, filesize ($filename));
    if (strlen($data) == 0) {
        break;
    }
    $contents .= $data;
}
fclose ($handle);

Maar misschien moet je wat anders gebruiken dan fread ?

Misshien heb je meer aan file of readfile? Beetje afhankelijk wat je probeert te doen...

[ACM]

LuCarD schreef op 15 July 2003 @ 12:40:
maw 2687 bytes is het eerste pakketje.

Bijzonder netwerk als het zulke grote packets heeft...

Maar ik gebruik om dit soort dingen te voorkomen meestal zoiets:

PHP:

while(!feof($fp))
{
  $htmldata .= fread($fp, 1024);
}

En als het om een fs ipv netwerk gaat maak ik van die 1024 meestal 4096 (de meest voorkomende blocksize)

[BramT]

LuCard, die "oplossing" die wordt gegeven heb ik natuurlijk geprobeerd... maar na een simpele c&p geeft DIE code een "expected T_WHILE code"-error op regel 10...

Ga de oplossing van creative 's proberen.

Ik snap dat gedoe van die "eerste" packet wel, alleen heb ik dezelfde code eerder gebruikt om pagina's van 100kb of meer te laden zonder problemen.... maar dat was op een andere server; misschien dat dat uitmaakt..

[ACM]

BramT schreef op 15 July 2003 @ 12:53:
LuCard, die "oplossing" die wordt gegeven heb ik natuurlijk geprobeerd... maar na een simpele c&p geeft DIE code een "expected T_WHILE code"-error op regel 10...

Hij is blijkbaar de while vergeten, maar die oplossing van creative is exact hetzelfde als wat je eerst had, hooguit dan nog de 4.3.0 specifieke methoden van php niet.

[BramT]

PHP:

while(!feof($fp)) 
{ 
  $htmldata .= fread($fp, 1024); 
}

werkt zonder problemen! bedankt mensen!

* BramT denkt dat het server afhankelijk is of je het in 1x kan doen of met een while moet werken....

[ Voor 32% gewijzigd door BramT op 15-07-2003 12:55 ]

[LuCarD]

ACM schreef op 15 juli 2003 @ 12:54:
[...]

Hij is blijkbaar de while vergeten, maar die oplossing van creative is exact hetzelfde als wat je eerst had, hooguit dan nog de 4.3.0 specifieke methoden van php niet.

Oops.... dom van me....

cut'n paste van de manual... maar niet gecontroleerd door mij.

[igmar]

ACM schreef op 15 July 2003 @ 12:50:

Bijzonder netwerk als het zulke grote packets heeft...

Dit zijn TCP / IP packets. Over het medium zijn ze inderdaad kleiner, maar aangezien de IP stack ze weer assembled merk je d'r als gebruiker niks van en krijg je een pakketje van max 65k.

[ACM]

igmar schreef op 15 July 2003 @ 13:41:
Dit zijn TCP / IP packets. Over het medium zijn ze inderdaad kleiner, maar aangezien de IP stack ze weer assembled merk je d'r als gebruiker niks van en krijg je een pakketje van max 65k.

Assembled ie ze weer? Ik meende dat ie eenmaal gefragmentte packets lekker gefragment liet...

[Soultaker]

ACM schreef op 15 July 2003 @ 13:44:
Assembled ie ze weer? Ik meende dat ie eenmaal gefragmentte packets lekker gefragment liet...

Als ik me niet vergis zit de fragmentation/reassembly functionaliteit in de IP layer. Daarboven gelegen layers zoals TCP en UDP krijgen dat gedrag dus kado, of ze nu willen of niet. Hoewel TCP dus inderdaad geen behoefte heeft aan reassembly (omdat er geen pakketjes met een specifieke grootte zijn) worden TCP frames waarschijnlijk toch wel samengevoegd in de IP layer.

Overigens zou het ook best kunnen dat er meerdere (kleinere) IP pakketjes binnengekomen zijn, sinds de verbinding geopend werd vanuit PHP, maar dat die toevallig nog niet ingelezen waren.

[ACM]

Soultaker schreef op 15 July 2003 @ 13:50:
Als ik me niet vergis zit de fragmentation/reassembly functionaliteit in de IP layer.

Dat zou goed kunnen idd, dan werden ze alleen bij het routeren niet weer samengevoegd, 't is alweer lang geleden dat ik dat gehad heb (zeker een jaar ).

Overigens zou het ook best kunnen dat er meerdere (kleinere) IP pakketjes binnengekomen zijn, sinds de verbinding geopend werd vanuit PHP, maar dat die toevallig nog niet ingelezen waren.

Maar wat ook precies de reden is, het is altijd verstandig om te kijken of de filepointer wel leeg is (tenzij het een udp-netwerk-pointer was, dan heb je daar niets aan en kan je dat maar beter niet eens proberen).

Maar dan nog, ook voor HTTP is die 2687 een rare grootte, volgens mij zit daar niet echt een maximale/minimale packetgrootte aan (en wordt dus indien mogelijk de MTU genomen, die toch echt vrijwel altijd rond de 1500 bytes ligt)??

[ Voor 14% gewijzigd door ACM op 15-07-2003 14:07 ]