Réponse tampon de servlet malgré les appels à rincer ()

i entièrement, je ne peux pas reproduire votre problème. Vous trouverez ci-dessous votre code, légèrement modifié, en cours d'exécution dans un serveur de jeton incorporé. Je l'ai couru à Intellij et demanda http: // localhost: 8080 de Firefox. Comme prévu, la boîte de dialogue "Enregistrer ou ouvrir" est apparu après 1 seconde. Sélection de "Enregistrer" et en attente de 20 secondes dans un fichier ZIP pouvant être ouvert et contient 20 entrées distinctes, nommée FOO chacune contenant une seule ligne 100 caractères de large et finissant avec . Ceci est sur Windows 7 Premium 64 avec JDK 1.6.0_26. Chrome agit de la même manière. C'est-à-dire, d'autre part, semble normalement attendre 5 secondes (500 octets), même une fois qu'il a montré la boîte de dialogue immédiatement, et une autre fois, il semblait attendre 9 ou 10 secondes. Essayez-la dans différents navigateurs:

import org.eclipse.jetty.server.Server;
import org.eclipse.jetty.servlet.ServletContextHandler;
import org.eclipse.jetty.servlet.ServletHolder;

import javax.servlet.ServletException;
import javax.servlet.http.*;
import java.io.IOException;
import java.util.zip.ZipEntry;
import java.util.zip.ZipOutputStream;

public class ZippingAndStreamingServlet {
    public static void main(String[] args) throws Exception {
        Server server = new Server(8080);
        ServletContextHandler context = new ServletContextHandler(ServletContextHandler.SESSIONS);
        context.setContextPath("/");
        server.setHandler(context);
        context.addServlet(new ServletHolder(new BufferingServlet()), "/*");
        server.start();
        System.out.println("Listening on 8080");
        server.join();
    }

    static class BufferingServlet extends HttpServlet {
        protected void doGet(HttpServletRequest request,
                             HttpServletResponse response) throws ServletException, IOException {
            ZipOutputStream _zos = new ZipOutputStream(response.getOutputStream());
            ZipEntry _ze;
            long startTime = System.currentTimeMillis();
            long _lByteCount = 0;
            int count = 1;
            response.setContentType("application/zip");
            response.setHeader("Content-Disposition", "attachment; filename=my.zip");
            while (_lByteCount < 2000) {
                _ze = new ZipEntry("foo" + count);
                _zos.putNextEntry(_ze);
                byte[] bytes = String.format("%100d", count++).getBytes();
                System.out.println("Sending " + bytes.length + " bytes");
                _zos.write(bytes);
                _lByteCount += bytes.length;
                sleep(1000);
                System.out.println("Zip: " + _lByteCount + " Time: " + ((System.currentTimeMillis() - startTime) / 1000));
                _zos.flush();
            }
            _zos.close();
        }

        private void sleep(int millis) {
            try {
                Thread.sleep(millis);
            } catch (InterruptedException e) {
                throw new IllegalStateException("Unexpected interrupt!", e);
            }
        }
    }
}

Il s'avère qu'il existe une limite sur la pile Apache / Windows IP sous-jacente qui tamponne les données d'un flux dans une tentative d'efficacité. Étant donné que la plupart des gens ont le problème de trop de données , pas le problème des données trop peu , c'est juste la plupart du temps. Ce que nous avons fini par faire était de demander à l'utilisateur de demander suffisamment de données que nous appuions la limite de 1000 octets avant de terminer. Désolé de prendre si longtemps pour répondre à la question.