[PHP] Surfen kan pas na download

[EnsconcE]

Ik heb nu een script dat "voorkomt" dat mensen kunnen hotlinken naar bestanden op de server, het probleem van mijn script is dat je pas weer kan verder surfen nadat de download voltooid is. Als ik bv met FF aan het downloaden ben, kan ik wel verder surfen met IE maar met FF gaat pas weer nadat de download voltooid is.

Mijn script ziet er als volgt uit:

PHP:

$downloadFile = $_GET['fileName'];

header('Content-type: audio/mp3');
header('Content-Length: '.filesize($downloadFile));
header('Content-Disposition: inline; filename="'.$downloadFile.'"');

readfile($downloadFile);

Wat in mijn code veroorzaakt dat? of is de opzet van mijn script verkeerd?

[frickY]

Ik begrijp niet wat je bedoeld?

Ik klik op een link in je site, waardoor een download start.
Ik kan vervolgens niet meer op andere links klikken tot mijn download is voltooid?

Zou je eerder een snaar het aantal threads per connectie van je webserver moeten kijken.

[Voutloos]

Offtopic, maar wel zeer belangrijk: check uiteindelijk wel de inhoud van $downloadFile, want nu kan je elk willekeurige bestand ophalen als kwaadwillende gebruiker.

[NMe]

Dit lijkt me sowieso een webserver issue, en niet iets dat met je code te maken heeft. Als je op de normale manier bestanden downloadt, heb je dit dan ook?

[EnsconcE]

@Voutloos:
Dat zeker, dit is ook maar een gedeelte van het script.

@frickY
Ik kan wel op andere links klikken, maar op dat moment gaat de website op "Loading" en loopt de blauwe balk pas wanneer de download gestopt is. Met andere woorden, Je kan klikken wat je wilt maar het laden begint pas echt wanneer de download voltooid is.

De webserver lijkt het niet te zijn, wanneer ik het bestand gewoon download dan kan ik wel verder surfen tijdens de download.

[ Voor 16% gewijzigd door EnsconcE op 31-08-2006 12:58 ]

[Janoz]

Dat heef tiig weinig met je code te maken. Aangezien het met IE wel werkt vermoed ik zelfs dat het een clientside probleem is (in Firefox of het gebruik van Firefox)

[EnsconcE]

Het probleem doet zich ook voor met IE, maar surfen kan ik dan wel weer met FF tijdens de download van IE. Hierbij kunnen we het client side verhaal wel afsluiten denk ik.

Wat is er dan server-side mis waardoor de website niet verder kan? En kan dit opgelost worden dmv code? Als ik mensen namelijk het bestand via HTML laat downloaden, wat ik ivm datalimiet wil voorkomen, dan kan men wel verder surfen wat in contrast staat met mijn script.wanneer rechtstreeks downloaden dat wel doet?

[ Voor 126% gewijzigd door Janoz op 31-08-2006 14:52 . Reden: Shit, drukte op edit ipv quote :X ]

[Verwijderd]

Je server accepteert waarschijnlijk slechts 1 connectie per sessie. Aangezien je data als 1 groot http pakket over de lijn gaat worden er pas na de download weer connecties binnen die sessie geaccepteerd.

[Janoz]

Als ik mensen namelijk het bestand via HTML laat downloaden, wat ik ivm datalimiet wil voorkomen

Deze opmerking vind ik uitermate vreemd. Wat wil je precies bereiken en waarom denk je dat een bestand via php niet meeteld voor je datalimi

[EnsconcE]

Janoz schreef op donderdag 31 augustus 2006 @ 14:52:
[...]


Deze opmerking vind ik uitermate vreemd. Wat wil je precies bereiken en waarom denk je dat een bestand via php niet meeteld voor je datalimi

Offtopic:
Juist wel, alles wat gedownload wordt telt mee voor het datalimiet. Maar omdat ik mensen nu via php laat downloaden kan ik de downloads onder controle houden. Hiermee voorkom ik dat mensen een directe link naar het mp3 bestand zetten waardoor mijn datalimiet makkelijker overschreden kan worden. Nu kan ik het downloaden stop zetten op bijvoorbeeld 1,8 gig(er vanuit gaande dat het limiet 2 gig is) en op die manier kan de website nog gewoon bezocht worden zonder dat het datalimiet "eenvoudig" overschreden wordt.

[ Voor 3% gewijzigd door EnsconcE op 31-08-2006 14:58 ]

[frickY]

Gebruik je toevallig een sessie in je download-script dan?
In dat geval dien je deze eerst te sluiten alvorens je de download start.

De sessie variabele blijft anders gelocked, waardoor de andere pagina hier geen toegang tot heeft.
Zet eens session_write_close() zodra je de sessie niet meer nodig hebt, en voordat je de download begint.

[mocean]

EnsconcE schreef op donderdag 31 augustus 2006 @ 14:56:
[...]


Offtopic:
Juist wel, alles wat gedownload wordt telt mee voor het datalimiet. Maar omdat ik mensen nu via php laat downloaden kan ik de downloads onder controle houden. Hiermee voorkom ik dat mensen een directe link naar het mp3 bestand zetten waardoor mijn datalimiet makkelijker overschreden kan worden. Nu kan ik het downloaden stop zetten op bijvoorbeeld 1,8 gig(er vanuit gaande dat het limiet 2 gig is) en op die manier kan de website nog gewoon bezocht worden zonder dat het datalimiet "eenvoudig" overschreden wordt.

Al dat je doel is, is er ook nog wel een andere mogelijkheid. Als je op je webserver een control panel hebt draaien, of een van de bekende statistieken-scripts, kan je daaruit halen hoever je zit met traffic t.o.v. je datalimiet. Voordeel is dat alle traffic vanaf je server dan wordt geteld.
Dit getal kan je bijvoorbeeld om de zoveel minuten checken, en e.v.t. de downloads tijdelijk disablen.

[Helza]

En als je Content-Disposition: attachment; gebruikt ipv inline lost dat het probleem op?

.. dan wordt het bestand namenlijk "toegestuurd" inplaats van in de browser geladen en deze dus vast houd..

[EnsconcE]

frickY schreef op donderdag 31 augustus 2006 @ 15:01:
Gebruik je toevallig een sessie in je download-script dan?
In dat geval dien je deze eerst te sluiten alvorens je de download start.

De sessie variabele blijft anders gelocked, waardoor de andere pagina hier geen toegang tot heeft.
Zet eens session_write_close() zodra je de sessie niet meer nodig hebt, en voordat je de download begint.

Bedankt voor deze oplossing , het downloaden gaat nu prima naast het surfen.

mocean schreef op donderdag 31 augustus 2006 @ 15:04:
[...]


Al dat je doel is, is er ook nog wel een andere mogelijkheid. Als je op je webserver een control panel hebt draaien, of een van de bekende statistieken-scripts, kan je daaruit halen hoever je zit met traffic t.o.v. je datalimiet. Voordeel is dat alle traffic vanaf je server dan wordt geteld.
Dit getal kan je bijvoorbeeld om de zoveel minuten checken, en e.v.t. de downloads tijdelijk disablen.

Dat is idd mogelijk, maar waar is de uitdaging?

Helza schreef op donderdag 31 augustus 2006 @ 15:05:
En als je Content-Disposition: attachment; gebruikt ipv inline lost dat het probleem op?

.. dan wordt het bestand namenlijk "toegestuurd" inplaats van in de browser geladen en deze dus vast houd..

Dit was niet de oplossing, had ik namelijk al geprobeerd.

[ Voor 13% gewijzigd door EnsconcE op 31-08-2006 16:32 ]

[Verwijderd]

Volgens mij is het Content-length en Content-disposition, dus zonder tweede hoofdletter, wellicht dat dat uitmaakt .

[frickY]

Nee, de hoofdletters kloppen.
Het enige verschil met disposition inline en attachment is de manie rwaarop je browser het aanbied.

Inline probeerd deze het zelf te tonen, attachment wordt he tbestand naar een bestand opgeslagen. Op beide methodes werkt de download echter hetzelfde.