[PHP/HTTP] Transfer-Encoding: chunked wil maar half

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • mux
  • Registratie: Januari 2007
  • Laatst online: 18-09 16:37

mux

99% efficient!

Topicstarter
Ik heb een probleem waar ik niet echt uitkom, ik ben zeker niet onervaren met de materie maar ik heb het idee dat ik in dit geval iets over het hoofd zie. Ik kan er ook niks over vinden op interwebs. Het gaat om het volgende:

Mijn doelstelling is om een soort van streaming connectie te openen naar een website. XMLHTTPRequest wil dit niet (ondersteunt geen readystate=3 responsetext uitlezen, althans zeker niet in alle browsers) dus dan maar met een chunked pagina in een hidden frame. Voor een proof of concept heb ik de simpelst mogelijke vorm geschreven waarin ik wat controle heb:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<?php
header("Cache-Control: no-cache, must-revalidate");
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Transfer-Encoding: chunked");
$a = 0;

ob_start();
echo "\r\n";
while($a < 10)
{
 $a++; 
 echo "15\r\n";
 echo microtime()."\r\n";
 ob_flush();
 flush();
 
 //sleep(1);
}

echo "0\r\n\r\n";
ob_end_flush();
?>


Deze woont voorlopig in een iframe op een lege pagina. Volgens mij is dit correct: headers zijn vziw correct, format is OK. Die output buffer is bedoeld om php tussentijds te laten zenden naar Apache, dat doet PHP ook wel maar Apache buffert daarna gezellig weer waardoor de fysieke chunkedness in de soep loopt (het komt allemaal alsnog in één packet binnen). Dat is allemaal niet van belang, dat komt later wel, nu is het probleem:

[de output van] deze code doet het wel in Firefox, maar niet in Chrome

Sterker nog, als ik wat klooi in m'n code (en strikt genomen zelfs wat fouten introduceer, zoals verkeerde chunk sizes) doet het het alsnog vrij goed. Firefox lijkt vrij gemakkelijk om te springen met het geheel en zeurt niet. Chrome geeft altijd een:

code:
1
Error 320 (net::ERR_INVALID_RESPONSE): Unknown error.


En internet explorer wil er ook weinig van laten zien, maar dat boeit me wat minder. Wat doe ik fout? Ik heb Wireshark er ook al lekker op los gelaten en deze zegt dit:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
HTTP/1.1 200 OK
Date: Fri, 02 Sep 1988 11:32:57 GMT
Server: Apache/2.2.9 (Win32) PHP/5.2.8
X-Powered-By: PHP/5.2.8
Cache-Control: no-cache, must-revalidate
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Transfer-Encoding: chunked
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/html


15
0.95024700 589203177
15
0.95047100 589203177
15
0.95055700 589203177
15
0.95057900 589203177
15
0.95060200 589203177
15
0.95062300 589203177
15
0.95064500 589203177
15
0.95066700 589203177
15
0.95068900 589203177
15
0.95071100 589203177
0


de server is een laptop die aan de muur hangt met kapotte RTC batterij die denkt dat het 1988 is

Acties:
  • 0 Henk 'm!

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
Gokje, maar gooit die expires header geen roet in het eten. Het bestand is al verlopen zeg maar, waarom dan nog wachten op extra bytes ipv gewoon een nieuw bestand op te halen?

Acties:
  • 0 Henk 'm!

  • mux
  • Registratie: Januari 2007
  • Laatst online: 18-09 16:37

mux

99% efficient!

Topicstarter
Maar dat is het fundamentele probleem nu nog even niet: nu wil het gewoon niet in chrome of IE. Nu ik het test maakt het overigens ook niet uit, en dat wist ik al want op mijn werkcomputer (waar ik heb eerder draaide voordat ik packets ging sniffen) staan data etc. wel goed, en had ik ook een 'over vijf seconden loopt-ie af'-header erin gesnoept.

Acties:
  • 0 Henk 'm!

  • mux
  • Registratie: Januari 2007
  • Laatst online: 18-09 16:37

mux

99% efficient!

Topicstarter
Nou, mn probleem is (grootendeels) opgelost, het bleek aan de output buffer te liggen. Ik ga weer even verder (en kijken hoe ik de output buffer alsnog tussentijds geleegd krijg)

edit: right, nu doet ie het opeens wel met output buffer. Iets met de gouden regel van het programmeren: 'probeer het nog eens, misschien doet ie het dan wel'.

[ Voor 31% gewijzigd door mux op 02-01-2009 19:46 ]


Acties:
  • 0 Henk 'm!

Verwijderd

Met je chrome gerelateerde probleem kan ik je niet helpen, maar de uitvoer van PHP is AFAIK altijd chunked. De volgende code lever bij mij chunked uitvoer op:

code:
1
2
3
4
5
6
7
8
9
10
11
<?php
$a = 0;

while($a < 10)
{
 $a++; 
 echo microtime();
 flush();
 sleep(1);
}
?>


De uitvoer:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
HTTP/1.1 200 OK
Date: Fri, 02 Jan 2009 21:13:05 GMT
Server: Apache
X-Powered-By: PHP/5.2.8-pl1-gentoo
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

15
0.47434000 1230930785
15
0.47458200 1230930786
15
0.47468500 1230930787
15
0.47478500 1230930788
15
0.47489100 1230930789
15
0.47499700 1230930790
15
0.47509700 1230930791
15
0.47520200 1230930792
15
0.47530500 1230930793
15
0.47540800 1230930794
0

Acties:
  • 0 Henk 'm!

  • mux
  • Registratie: Januari 2007
  • Laatst online: 18-09 16:37

mux

99% efficient!

Topicstarter
Ja, dat ligt dus weer aan Apache, PHP en die ongein. Ik wilde het betrouwbaarder (voor een server die het toevallig niet standaard deed als ik flushte)

Maargoed, dit werkt ook voor geen meter dus ik gebruik maar gewoon flush() met 1024 leading bytes. Vervelend dat PHP en Apache niet iets nauwer kunnen samenwerken op dit punt.

Acties:
  • 0 Henk 'm!

Verwijderd

ssj3gohan schreef op vrijdag 02 januari 2009 @ 22:49:
Ja, dat ligt dus weer aan Apache, PHP en die ongein. Ik wilde het betrouwbaarder (voor een server die het toevallig niet standaard deed als ik flushte)

Maargoed, dit werkt ook voor geen meter dus ik gebruik maar gewoon flush() met 1024 leading bytes. Vervelend dat PHP en Apache niet iets nauwer kunnen samenwerken op dit punt.
Staat niet toevallig output buffering aan in je php.ini (controleer de waarde van ob_get_status() om het helemaal zeker te weten).

Server-side compressie zoals bijvoorbeeld mod_deflate (bij apache) buffert ook en trekt zich niets aan van een flush() in php. Deze dient dan ook uitgeschakeld te worden voor je scripts die willen flushen.

Maar zoals je al zegt is het lastig om fatsoenlijk aan de gang te krijgen, ook aan de client kant. Ik liep onlangs ook tegen dit probleem aan en heb er voor gekozen, omdat er toch maar een beperkt aantal simultane gebruikers zijn, om te pollen. Dat werkt tenminste altijd.

Acties:
  • 0 Henk 'm!

  • mux
  • Registratie: Januari 2007
  • Laatst online: 18-09 16:37

mux

99% efficient!

Topicstarter
Ik heb niet echt de keuze om in mn php.ini te gaan klooien want wat ik wil maken moet zomaar gaan werken op elke 'redelijk' geconfigureerde website (relatief exotische dingen als gzip/deflate staan dan wel uit, maar er kan van alles gebeuren met buffering). De enige vrijheid die ik heb is klooien met .htaccess en spul in de php zelf.

Op mn eigen servertje kan ik natuurlijk alles forceren wat ik wil en van mijn part een C handler schrijven, maar dat is niet helemaal de bedoeling ;)
Pagina: 1