Служите содержанию Gzipped с Сервлетами Java

Depending on your container, the container will most likely do this for you. It may do it automatically, or you might need to manually configure it to do it for you. The advantage of this method is zero code changes. And, again, depending on container, you can conditionally enable/disable the compression based on where the request comes from or source browser.

For Tomcat, have a look at the compression attribute on the HTTP config pages (v5.5, v6.0).

Посмотрите на класс GzipOutputStream. Примерно так:

response.setContentType(...)
GzipOutputStream os = new GzipOutputStream(response.getOutputStream);
//write to os
Writer writer = new PrintWriter(os);

Затем используйте Writer как обычно.

If you are on Tomcat, the connector can do compression for you. This is my configuration,

<Connector port="8000"
 compression="on" 
 compressionMinSize="1024" 
 compressableMimeType="text/html,text/xml" 
 ...
/> 

If you run Apache httpd in front of Tomcat, you should use mod_gzip, which does a much better job.

Если вы действительно, действительно не хотите больше возиться с кодом Java, вы также можете рассмотреть возможность подключения сервера Apache перед вашим контейнером сервлетов.

Если у вас есть много статического содержимого, это может улучшить производительность для вас, поскольку Apache будет работать со статическими страницами немного быстрее, чем любой контейнер сервлетов. Таким образом, вы должны настроить его только для делегирования запросов сервлетов вашему контейнеру сервлетов на локальном хосте.

Apache имеет удобные встроенные параметры для сжатия вывода. Не помню, как их настраивать, но это легко и универсально. Он согласовывает с браузерами, что они могут обрабатывать, и так далее. В случае сомнений, Apache, как правило, будет более сообразительным и современным в методах сжатия, чем любой контейнер Java.

Просто хотел сообщить вам, чем я закончил.

Я сделал обертку класса запроса, которая выглядит так:

public class GzippedResponse extends HttpServletResponseWrapper{

  private PrintWriter pw;

  private GzippedResponse(HttpServletResponse response){
    super(response);
    try{
      pw = new PrintWriter(new GZIPOutputStream(response.getOutputStream()));
    }catch(Exception e){
      throw new ApiInternalException("Failed to create a Gzipped Response", e);
    }
  }

  public static GzippedResponse wrap(HttpServletResponse response){
    return new GzippedResponse(response);
  }

  @Override
  public PrintWriter getWriter() throws IOException {
    return pw;
  }  
}

А затем на моем BaseAction ], который, по сути, является TemplateMethod для других «действий». Я оборачиваю ответ следующим образом:

if(supportsCompression(request)){
  response.setHeader("Content-Encoding", "gzip");
  response = GzippedResponse.wrap(response);
}
action.macroExecute(request,response);

Я думаю, что он достаточно чистый. Если вы найдете что-то, что можно улучшить, сообщите мне. Спасибо всем за ответы!

Есть два основных способа:

• Настроить на сервере приложений. Например, в Tomcat вам просто нужно установить атрибут сжатия коннектора в conf / server.xml на на .
• ] Оберните response.getOutputStream () в new GzipOutputStream () и вместо этого напишите в него.

Первый способ влияет на все веб-приложение, но это действительно не должно повредить , это почти нулевые усилия и большое преимущество для производительности. И, что более важно, в отличие от второго способа он фактически проверяет заголовки запроса, если клиент поддерживает Gzip, перед его использованием. Когда вы идете по второму пути без подключения к Интернету, около 10% пользователей всемирной паутины не смогут получить доступ к вашему веб-приложению. На самом деле это не простая задача.

Вы можете найти здесь расширенный пример FileServlet , который поддерживает каждый Gzip и проверяет его на основе заголовков запроса. Вы можете получить новое понимание.