octets en streaming de contrôleur, navigateur Android, téléchargement échoue

Question

Grails 1.3.7

J'ai un code qui ressemble à ceci ...

response.setHeader("Content-disposition", "attachment; filename=${fileName}") 
response.contentType = download.contentType 
response.contentLength = file.length() 
response.outputStream << file.getBytes() 

Sur le bureau et sur l'iPad, les téléchargements fonctionnent ça va. Mais sur les appareils Android, il me donne juste "Unknown myserver.com En cours". Et puis échoue finalement. Un couple de points ...

• Ce dans leur environnement local, la mise en scène, et sur les serveurs de production
• Test sans SSL, tout fonctionne bien.
• Lorsque je tente le téléchargement dans le navigateur Dolphin I obtenir les mêmes résultats avec un bit ajouté de texte « En attente de connexion de données »

Mise à jour # 2: Stacktrace que ne se produit que lors du téléchargement d'un appareil Android:

Stacktrace follows: 
java.net.SocketException: Broken pipe 
    at java.net.SocketOutputStream.socketWrite0(Native Method) 
    at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) 
    at java.net.SocketOutputStream.write(SocketOutputStream.java:136) 
    at com.sun.net.ssl.internal.ssl.OutputRecord.writeBuffer(OutputRecord.java:297) 
    at com.sun.net.ssl.internal.ssl.OutputRecord.write(OutputRecord.java:286) 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:743) 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:731) 
    at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59) 
    at com.wbr.consumer.ProductController$_closure1_closure2.doCall(ProductController.groovy:30) 
    at com.wbr.consumer.ProductController$_closure1.doCall(ProductController.groovy:28) 
    at com.wbr.consumer.ProductController$_closure1.doCall(ProductController.groovy) 
    at java.lang.Thread.run(Thread.java:680) 

Answer 1

On dirait que il y a potentiellement 2 numéros

1. le navigateur que vous utilisez ne fait pas confiance au certificat autosigné.

   • Les autres sites SSL fonctionnent-ils à partir de ce navigateur?
   • Pouvez-vous installer votre certificat STG dans le magasin de certificats de confiance du navigateur?
   • Une question stupide est: avez-vous obtenu l'URL de la demande correcte? https vs http ... je sais que c'est stupide .....

2. la réponse n'est jamais vidée vers le client. Essayez ceci:

   • response.outputStream.flush()

Answer 2

Je sais que cela est quelques mois de retard mais j'ai aussi rencontré ce problème avec le navigateur Android et une application Grails j'étais travaille sur.

Le problème semble être comment Android gère le contenu téléchargeable et l'intégration du navigateur Android avec gestionnaire de téléchargement.

http://code.google.com/p/android/issues/detail?id=1978

http://code.google.com/p/android/issues/detail?id=18462

je recevais deux demandes sur le côté serveur pour un fichier téléchargeable; un du navigateur et un du gestionnaire de téléchargement. Celui du navigateur finit par se terminer et le socket est fermé dès que le navigateur détermine qu'il s'agit d'un contenu téléchargeable. Le navigateur transmet alors le téléchargement au gestionnaire de téléchargement.

J'avais également des problèmes avec le téléchargement échouant du gestionnaire de téléchargement mais cela a dû pour raison ne m'envoyant pas les en-têtes dès qu'ils étaient prêts.Je suis tombé sur ceci seulement avec de plus grands APKs, de petits APKs (moins de 10-20K) semblaient télécharger très bien.

Certains code peut aider:

response.contentType = 'application/vnd.android.package-archive' 
    response.addHeader('Content-Disposition', 'attachment; filename=FILENAME.APK') 

    // output file content 
    response.setStatus(200) 
    response.setContentLength("CONTENTSIZE") 

    // send headers 
    response.flushBuffer() 

    try { 
     response.outputStream << {FILE}.getBytes() 
     response.outputStream.flush() 
    } catch (SocketException e) { 
     log.error(e) 
    } 
    return 

Avec cela, je finis toujours à une exception près de la prise. Je ne sais pas si c'est évitable, d'une recherche rapide, je n'ai pas vu un moyen de déterminer l'état du socket de servlet sans simplement essayer d'écrire sur le socket.