perl script onder apache trager dan op command-line?

Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> [http/1.1 en ontbrekende contentlength]
>
>> > Kun je je webserver zo instellen dat ie dat wel gaat berekenen ?
>>
>> Geen idee eigenlijk, ik maak al jaren geen gebruik meer van losse CGI
>> scripts. Zo te zien doet PHP ook niet aan content-length's, dus het is
>> misschien een idee om eerst eens met de instellingen van Mozilla te
>> spelen om te zien of het daar uberhaupt wel aan ligt :)
>
> Hmmmm, wat zegt de rfc (2616) over dit geval? Ik zou overigens
> verwachten dat indien een browser een 1.1 request doet en een script
> geen content-length meegeeft de zut chunked zou worden verstuurd door de
> webserver.

Zo te zien is dat zo. Een andere mogelijkheid is dat de server de connectie
dichtgooit als alles verzonden is.

--
robert

robert schreef:
> Michiel de Roo <michiel@mderooPUNTNL>:
> > robert wrote:
> >> Het zou er mee te maken kunnen hebben dat Mozilla ingesteld staat op
> >> HTTP/1.1 requests (Advanced > HTTP Networking), je webserver voor de
> >> uitvoer van je script geen Content-Length berekent, en je browser
> >> blijft wachten op nieuwe data van de webserver, die er nooit komt.
> >
> > Kun je je webserver zo instellen dat ie dat wel gaat berekenen ?
>
> Geen idee eigenlijk, ik maak al jaren geen gebruik meer van losse CGI
> scripts. Zo te zien doet PHP ook niet aan content-length's, dus het is
> misschien een idee om eerst eens met de instellingen van Mozilla te spelen
> om te zien of het daar uberhaupt wel aan ligt :)
>

Inderdaad! Ik heb nu HTTP/1.0 ingesteld en het gaat veel sneller!
Misschien heb je zin om te vertellen wat het verschil is?

Arjen Haayman

Arjen Haayman <ahaayman@deadspam.com>:
<snip>
> Inderdaad! Ik heb nu HTTP/1.0 ingesteld en het gaat veel sneller!
> Misschien heb je zin om te vertellen wat het verschil is?

Een nadeel van het oude HTTP protocol was dat de browser voor elk extern
element van een webpagina (plaatjes, externe stylesheets, externe
JS-scripts, enzovoort) een nieuwe verbinding met de webserver moest
opzetten, en juist zo'n nieuwe verbinding opzetten kost (relatief) veel
tijd.

Met de 1.1 versie is het mogelijk om meerdere requests (en responses)
binnen één 'sessie' met de server af te handelen. Een browser moet dan wel
weten wanneer de response van de server klaar is, voordat er weer een nieuw
request opgestuurd kan worden.

Meestal kan de browser dat bepalen aan de hand van de door de server
meegegeven Content-Length header; dat is in feite de manier van de server
om te zetten 'oké, er komt nu een hoeveelheid data naar je toe, en wel van
zus-en-zoveel bytes groot'. De browser leest die hoeveelheid bytes, en gaat
er dan van uit dat er weer een nieuw request gestuurd kan worden.

Bij CGI-scripts zit je alleen met het probleem dat de server de grootte
van de data over het algemeen niet kan bepalen, omdat het niet gaat om een
bestand (zoals een simpele HTML pagina of een plaatje) waar makkelijk de
grootte van bepaald kan worden.

En dus kan de server geen Content-Length meesturen (tenzij de server de
complete uitvoer van het CGI script eerst buffert en er dan de lengte van
bepaalt, maar dat kan potentieel problematisch zijn.

Kennelijk gaat Mozilla een bepaalde tijd zitten wachten voordat 'ie
doorheeft dat er geen uitvoer meer van de server komt, en tot die tijd laat
je browser niks zien (of hij laat de uitvoer niet volledig zien, ik weet
niet precies wat je specifieke klachten waren).

Als je 1.0 aanzet dan gooit de server na het opsturen van de uitvoer van
je script de verbinding dicht, en dat is voor Mozilla het teken dat de
response klaar is (zodat 'ie niet hoeft te gaan wachten).

Gebruik je misschien een oude versie van Mozilla? Want ik kan me niet
herinneren dat mijn Mozilla hetzelfde probleem heeft.

--
robert

> Gebruik je misschien een oude versie van Mozilla? Want ik kan me niet
> herinneren dat mijn Mozilla hetzelfde probleem heeft.

neuh. Ik gebruik 1.6

Dus de oplossing is om de content-length mee te geven?
Ik zal eens kijken of ik dat voor elkaar krijg.
Overigens: waarom kan bij PHP wel de content-lenth worden meegegeven?
Dat zijn toch ook dynamische scripts waar run-time steeds meer content
bij kan komen?

Arjen Haayman

Arjen Haayman <ahaayman@hotmail.com>:
>> Gebruik je misschien een oude versie van Mozilla? Want ik kan me niet
>> herinneren dat mijn Mozilla hetzelfde probleem heeft.
>
> neuh. Ik gebruik 1.6
>
> Dus de oplossing is om de content-length mee te geven?

Dat zou het probleem wel moeten oplossen, zou ik denken.

> Ik zal eens kijken of ik dat voor elkaar krijg.

Lastig, zeker vanuit een CGI omdat je pas na het genereren van de complete
uitvoer weet hoeveel data je gaat opsturen. Misschien dat Apache er een
mogelijkheid voor heeft, anders moet je aan de slag met outputbuffering
(wat in Perl overigens ook niet zo'n probleem is, daar bestaan AFAIK
modules voor).

> Overigens: waarom kan bij PHP wel de content-lenth worden meegegeven?

De gemiddelde PHP pagina stuurt zo te zien ook geen Content-Length mee.

--
robert

robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> > Dus de oplossing is om de content-length mee te geven?
>
> Dat zou het probleem wel moeten oplossen, zou ik denken.

Geen persistent connections gebruiken in het probleem script:
'Connection: close'

> > Overigens: waarom kan bij PHP wel de content-lenth worden meegegeven?
>
> De gemiddelde PHP pagina stuurt zo te zien ook geen Content-Length mee.

Dat is natuurlijk ook moeilijk te weten bij dynamische paginas. Als je
die wilt meesturen zal je dat zelf moeten doen (door de hele output te
bufferen en als laatste nog snel even de content-length in de headers
proppen).

--

Daniel Tryba

Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
>> De gemiddelde PHP pagina stuurt zo te zien ook geen Content-Length mee.
>
> Dat is natuurlijk ook moeilijk te weten bij dynamische paginas.

Mijn webserver (mod_perl, Apache::ASP, XML en XSLT) stuurt ze netjes mee,
zonder dat ik er iets voor hoef te doen zelfs ;)

--
robert

robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> >> De gemiddelde PHP pagina stuurt zo te zien ook geen Content-Length mee.
> >
> > Dat is natuurlijk ook moeilijk te weten bij dynamische paginas.
>
> Mijn webserver (mod_perl, Apache::ASP, XML en XSLT) stuurt ze netjes mee,
> zonder dat ik er iets voor hoef te doen zelfs ;)

Je stuurt je pagina's dan ook gecompressed op. Als je dat aan Apache
overlaat heeft die de pagina al geheel gebuffered en weet dus ook de
content-length.

--

Daniel Tryba

Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
>
>> >> De gemiddelde PHP pagina stuurt zo te zien ook geen Content-Length
>> >> mee.
>> >
>> > Dat is natuurlijk ook moeilijk te weten bij dynamische paginas.
>>
>> Mijn webserver (mod_perl, Apache::ASP, XML en XSLT) stuurt ze netjes
>> mee, zonder dat ik er iets voor hoef te doen zelfs ;)
>
> Je stuurt je pagina's dan ook gecompressed op.

Alleen bij browsers die dat aankunnen, met het handje overgehaalde pagina's
hebben ook een Content-Length. Alhoewel mod_gzip misschien daar toch tussen
zit...

--
robert