[Javascript] location.href en php file download

[B-Man]

Als ik vanuit javascript een URL aanroep, een php script dat m.b.v. headers & data een file naar de client stuurt, dan gaat dit mis.

Concreet voorbeeld:

ik heb een tabel:

code:

<table border=0>
  <tr onClick="location.href='downloadfile.php'">
    <td>klik op deze row</td>
  </tr>
</table>

Als ik het script vanuit een

code:

<a href='downloadfile.php'>test</a>

aanroep, gaat het wel goed. Als ik echter op de tr in het eerste blokje code klik, krijg ik netjes het "Bestand downloaden" venster. Echter, als ik dan op "ok" klik, dan krijg ik een foutmelding:

Internet Explorer kan deze website niet openen. De gevraagde website is niet beschikbaar of kan niet worden gevonden. Probeer het later opnieuw.

Deze fout krijg ik consequent van internet explorer (versie 5.0, 5.5, 6.0) op verschillende computers, en dus enkel als ik de url aanroep vanuit javascript.

Weet iemand hier een workaround voor? Ik ga zelf aan het spelen met een dynamische iframe denk ik, om te zien of dat wel werkt, maar dat vind ik nogal ranzig.

Overige info: alle geteste computers draaien op windows 2000 >= SP3, met IE 5.0, 5.5 of 6.0;

[Johnny]

Wat is er mis met gewoon een link naar het bestand maken? Als je toch met onclick werkt?

[B-Man]

Johnny: wat bedoel je? Kun je pseudocode geven, zodat het wat duidelijker is wat je bedoelt?

[dArtagnan]

Je kunt toch gewoon met een link naar een bestand downloadfile.php verwijzen en dan in het bestand de download aanroepen. Ik neem niet aan dat je wilt dat mensen downloadfile.php dowloaden.

En wat Johnny bedoelt: onClick="location.href='bestandomtedownloaden.exe'"

[Verwijderd]

uhm ..
het is toch :

document.location="blabka.exe"

of niet ?

[crisp]

Verwijderd schreef op 09 augustus 2003 @ 18:31:
uhm ..
het is toch :

document.location="blabka.exe"

of niet ?

nee, het is document.URL (read-only) of window.location waarvan href de default property is die je set. document.location mogen ze wat mij betreft de deur uitgooien, het is bij god's gratie dat het nog werkt in de meeste browsers...

[B-Man]

Ik genereer in het PHP script content (een database export o.a.), vandaar dat ik niet direct naar een file kan linken. Het lijkt erop dat IE echt een muisklik moet hebben om de een of andere reden...

[WPN]

heb je al geprobeert er onClick="javascript:location.href='downloadfile.php'" van te maken?

[Spider.007]

B-Man schreef op 09 augustus 2003 @ 18:51:
Ik genereer in het PHP script content (een database export o.a.), vandaar dat ik niet direct naar een file kan linken. Het lijkt erop dat IE echt een muisklik moet hebben om de een of andere reden...

Dat lijkt me onzin; maar je weet het nooit met IE... Heb je al echte browsers gebruikt waarin je eventueel wat debugging kan doen? Wat zeggen je access logs Zit er verschil tussen beiden verzoeken?

[ Voor 5% gewijzigd door Spider.007 op 09-08-2003 19:04 ]

[dArtagnan]

B-Man schreef op 09 August 2003 @ 18:51:
Ik genereer in het PHP script content (een database export o.a.), vandaar dat ik niet direct naar een file kan linken. Het lijkt erop dat IE echt een muisklik moet hebben om de een of andere reden...

Kun je niet een pop-up open met daarin het php-bestand, dan start vanuit de pop-up de download.

[crisp]

B-Man schreef op 09 augustus 2003 @ 18:51:
Ik genereer in het PHP script content (een database export o.a.), vandaar dat ik niet direct naar een file kan linken. Het lijkt erop dat IE echt een muisklik moet hebben om de een of andere reden...

check je de referrer soms in je script?

[B-Man]

Spider.007: access log toont geen verschil in aanvragen

Koraalduivel: ja, dat kan natuurlijk, maar dat creeert weer wat ranzige code. Het gaat niet om een script, maar om meerdere scripts. Ik kan de popup wel openen, maar dan moet ik na de download op de een of andere manier de popup weer sluiten. Code die er eigenlijk niets mee te maken heeft.

crisp: nee, dat niet. Werk wel met sessies. Kan het zijn dat IE de session-id cookie niet doorgeeft? Het gaat namelijk om een beveiligd script: ik controleer enkele sessie variabelen en database gegevens op geldigheid. Als de gegevens niet kloppen wordt er een redirect header verzonden... Daar zou het probleem kunnen zitten...

--edit

Al bedenk ik me net dat het niet aan de sessie kan liggen, aangezien de download-headers pas verzonden worden na de sessie-validatie, en ik wel netjes een "Bestand downloaden" venster krijg, wat inhoud dat de headers goed doorkomen.

Morgen nog maar wat meer testen. Heb in ieder geval weer wat ideeen.

Oh, en peluso: onClick is een javascript event, wat inhoud dat ik direct javascript code in kan geven. In een handler die een url verwacht kun je "javascript:" gebruiken om IE te melden dat er javascript code verwerkt dient te worden.

[ Voor 29% gewijzigd door B-Man op 10-08-2003 00:22 ]

[B-Man]

Ben iets wijzer geworden inmiddels, echter nog geen oplossing.
Als ik de link in een nieuw browservenster plak, met de PHPSESSID eraan geplakt (ja, op een correcte manier), krijg ik dezelfde foutmelding van IE.

Mijn HTTPD access log geeft in alle gevallen netjes een code 200 aan, wat betekent dat de data netjes naar de client gestuurd wordt. Het lijk dus aan IE te liggen.
Zal morgen opera eens installeren, om te zien of het daar ook misgaat.

[B-Man]

Heb een werkende oplossing: vond via google in een nieuwsgroep wat info over cache problemen met IE, en vond een link naar wat info hierover op de php site:

http://www.php.net/manual...session-cache-limiter.php

Het is op te lossen door als eerste regel in mijn script

PHP:

session_cache_limiter('public');

te zetten.

Pfff, ik zat al een jaar tegen dit probleem aan te hikken, eindelijk een oplossing

[creative8500]

Maar: waarom gebruik je geen link? Wanneer je die <td> en <a> met CSS opmaakt kun je precies hetzelfde bereiken. Onclick-linkjes zijn net zo fout als font-tags

[B-Man]

creative: omdat ik een groter gebied dan enkel de link-tekst aanklikbaar wil maken. Ik heb een menubar die opgemaakt wordt vanuit een DHTML behavior (site is IE only, webapp).