Tomcat Compression não adiciona um Content-Encoding: gzip no cabeçalho

StackOverflow https://stackoverflow.com/questions/550024

  •  23-08-2019
  •  | 
  •  

Pergunta

Eu estou usando Tomcat para compactar o meu conteúdo HTML assim: 

<Connector port="8080" maxHttpHeaderSize="8192"
maxProcessors="150" maxThreads="150" minSpareThreads="25"
maxSpareThreads="75" enableLookups="false" redirectPort="8443"
acceptCount="150" connectionTimeout="20000" disableUploadTimeout="true"
compression="on" compressionMinSize="128" noCompressionUserAgents="gozilla, traviata"
compressableMimeType="text/html"
URIEncoding="UTF-8" />

No cabeçalho HTTP (como observado via YSlow), no entanto, não estou vendo 

Content-Encoding: gzip

resultando em uma pontuação YSlow pobres.

Tudo o que vejo é 

HeadersPost
Response Headers
Server: Apache-Coyote/1.1
Content-Type:   text/html;charset=ISO-8859-1
Content-Language:   en-US
Content-Length: 5251
Date:   Sat, 14 Feb 2009 23:33:51 GMT

Estou executando uma configuração Apache mod_jk Tomcat.

Como faço para conteúdo HTML compressa com Tomcat, e também tem que adicionar "Content-Encoding: gzip"? No cabeçalho

Foi útil?

Solução

Tenha um olhar em http://sourceforge.net/projects/pjl-comp-filter/ .

Outras soluções personalizadas podem ter vazamentos de memória.

Além disso, se você estiver usando mod_jk então certamente você não estiver usando o conector 8080 (que suporta compressão) para esses pedidos.

Outras dicas

Tomcat estará fazendo a compressão. No entanto, porque você está usando mod_jk Eu acho que você está recebendo você solicita via Apache na porta 80 em vez de tomcat em 8080 porto. Como uma tentativa experimento obter a sua página através da porta 8080 e, em seguida, verificando yslow você deve ver os cabeçalhos corretos.

Eu acho que o que está acontecendo é que o Apache é descompactar o conteúdo que está recebendo a partir de tomcat via mod_jk e depois de passar o conteúdo esvaziado on para o navegador.

Se você quiser usar mod_jk então você precisará configurar sua compressão sobre Apache ao invés de Tomcat.

Talvez a compressão Tomcat está se referindo não é gzip? É um tiro no escuro, mas pode estar relacionada com a compressão de espaço em branco, ou linha de corte.

Eu imagino Tomcat seria um pouco mais explícito a este respeito (aqui está esperando).

Temos o filtro gzip mencionado por duffmo correndo em nossa aplicação, o web.xml é algo como isto: 

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee web-app_2_4.xsd">

    <display-name>App-Web</display-name>

    <!-- FILTERS -->

    <!-- Gzip filter -->
    <filter>
        <filter-name>GZIPFilter</filter-name>
        <filter-class>weblogicx.servlet.gzip.filter.GZIPFilter</filter-class>
    </filter>

    [snip]    
</web-app>

Para melhorar o desempenho do lado do cliente global da aplicação web J2EE, você pode tentar WebUtilities java biblioteca.

Aqui está o link :: http://code.google.com/p/webutilities/ .

Ele fornece filtro, tag, componentes de servlet para aplicar várias práticas de desempenho do lado do cliente, resultando em maior classificação de desempenho contra PageSpeed ??/ YSlow.

Desde a versão 0.0.4 que ajuda com as seguintes práticas de desempenho.

  1. Minimizar solicitações HTTP - pode servir vários JS / arquivos CSS em uma solicitação
  2. Cliente Side Caching - acrescenta adequada Cache-Control, Expira cabeçalho
  3. Na mosca JS / minification CSS - usando YUICompressor
  4. Compression - suportes 2way compressão para gzip / deflate / compressa codificações
  5. Response Cache no servidor - para evitar o reprocessamento de recursos inalteradas
  6. Adicionar Codificação de caracteres - dar a conhecer navegador com antecedência

Também é / personalização altamente configurável contra MIME, URL ou User-Agents.

Eu tive uma olhada na documentação do Tomcat aqui: http://tomcat.apache.org/tomcat-5.5-doc/ config / http.html

Ele menciona usando compression="force" que funcionou para mim. Ele também diz que você pode definir um minimum number. Isso funcionou bem para mim 

<Connector port="8080" compression="256000" />

(compressa nada mais de 256Kb)

O valor padrão para compressableMimeType significava que eu não precisava desse atributo. Observe também que isso não acontece atributo lista CompressionMinSize.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top