Qualche tempo fa, durante lo sviluppo di un'applicazione web disponibile anche per palmari, mi sono imbattuto in un problema apparentemente strano. Premetto che l'applicazione fa uso di una connessione SSL 128 bit. Una particolare sezione prevede il download di files attraverso la classica pagina di "Download Manager" che, con la combinazione del Response.BinaryWrite e degli header Content-Type e Content-disposition*, restituisce il file selezionato.
Ma qui si presenta un *grosso* problema: su Pocket PC 2003 (ho potuto testare solo su questa versione) + SSL il content-disposition non funziona ed il file viene salvato con il nome della pagina (che nel mio caso è  download.aspx ). Come risolvere?

#1 Workaround (poco pulito)

Una prima soluzione può essere quella di reindirizzare su una connessione non protetta (http) se il client è un POCKET PC. Il problema, infatti, si verifica solo in connessioni https proprio a causa dell'encrypting. Ma la soluzione è decisamente bruttarella.

#2 Workaround

La seconda soluzione, più elegante, è quella di reindirizzare il client verso un percorso non esistente, ma indicando il nome del file che desideriamo. A questo punto gestiamo lato server l'errore 404 (pagina non trovata) e, dopo le opportune verifiche, eseguiamo le operazioni per consentire il download del file (Response.BinaryWrite). Il client, infatti, in mancanza del content-disposition utilizza il nome del file presente nella URL.

E' ovvio che l'anomalia non riguarda .NET, ma qualsiasi tecnologia web lato-server. Questo perchè il bug riguarda il client.

Note*

Content-Type imposta il tipo del file. es.: text/xml
Content-disposition imposta il nome del file da scaricare

powered by IMHO 1.2