É possível configurar nós HTTP e SOAP para utilizar compactação e descompactação HTTP no envio e no recebimento de mensagens.
Os nós podem ser configurados para compactar mensagens de pedido, aceitar e descompactar respostas e descompactar mensagens de entrada.
O transporte HTTP suporta o envio de dados compactados. Os campos de cabeçalho HTTP específicos são utilizados para indicar que os dados estão compactados e qual técnica de compactação foi utilizada. Quando um cliente HTTP faz um pedido de HTTP, ele pode especificar que aceita uma resposta compactada e também quais tipos de dados compactados são aceitos. As três técnicas de compactação suportadas pelo transporte HTTP são GZIP, deflate e compress.
O campo Accept-Encoding é utilizado em um pedido de HTTP para indicar quais codificações são aceitas em uma mensagem de resposta para o pedido. Esse campo é utilizado para especificar os valores de gzip, deflate, compress e identity, que não fazem distinção entre maiúsculas e minúsculas. Um valor de identity indica que os dados não devem ser compactados. Um curinga * indica que qualquer codificação é aceita. O campo Accept-Encoding também pode ficar vazio, indicando que nenhuma codificação é aceita.
O campo de cabeçalho Content-Encoding indica a codificação que é aplicada aos dados e pode conter os tokens de gzip, deflate e compress, mas não identity. Quando dados são compactados para uma mensagem HTTP, o campo Content-Encoding contém o nome da técnica de compactação que foi utilizada, permitindo que o destinatário identifique o esquema de compactação e descompacte de forma correta os dados da mensagem.
O campo de cabeçalho TE é utilizado em um cabeçalho de pedido para indicar quais codificações de transferência de extensão ele aceitará na resposta. Esse campo é semelhante ao Accept-Encoding.
O campo Transfer-Encoding é semelhante ao Content-Encoding, exceto que ele é uma propriedade da mensagem, e não da entidade. O campo Transfer-Encoding é utilizado principalmente para indicar que uma mensagem de resposta é dividida em partes. É possível receber um cabeçalho Transfer-Encoding que indique outras codificações de transferência, como "chunked, gzip". Nesse caso, gzip se aplica à transferência de dados, e não aos dados reais em si.
O WebSphere Message Broker suporta compactação e descompactação com os nós HTTP e SOAP usando os campos Accept-Encoding e Content-Encoding como a seguir:
Na compactação de uma mensagem HTTP de pedido, o nó verifica o campo Content-Encoding para determinar se os dados da mensagem já estão compactados. Se os dados já estiverem compactados no esquema especificado, não será necessário fazer uma compactação adicional. No entanto, se os dados existentes já estiverem compactados em uma codificação não especificada nas propriedades do nó, o nó fará uma compactação adicional no fluxo de bits compactado utilizando a codificação especificada nas propriedades do nó. O valor do campo Content-Encoding é atualizado para indicar a codificação adicional aplicada aos dados. Por exemplo, o valor do Content-Encoding de deflate,gzip indica que a mensagem deve ser descompactada primeiro utilizando deflate e depois descompactada utilizando gzip.
Os nós HTTP e SOAP não suportam valores de qualidade no campo Accept-Encoding, o que permite que um usuário especifique um peso preferencial de tipos de compactação para respostas. Quaisquer valores de qualidade no campo Accept-Encoding serão ignorados.
Os nós de pedido podem solicitar e processar respostas compactadas. É possível configurar os nós de pedido para indicar que a compactação nas respostas é permitida, e o nó descompacta automaticamente uma resposta compactada. O cabeçalho Accepts-Encoding é configurado para indicar que as técnicas de compactação GZIP e deflate são aceitas. Se o cabeçalho Accept-Encoding já estiver configurado, o nó não o sobrescreverá.
Se os nós de pedido ou AsyncResponse receberem uma resposta compactada por GZIP ou deflate, ela será descompactada, e qualquer indicação de cabeçalho de que a mensagem está compactada será removida. Se os nós receberem uma resposta compactada inválida ou uma função de compactação desconhecida, será levantada uma exceção indicando que os dados não puderam ser descompactados.
Os nós de pedido também enviam pedidos compactados. É possível configurar o nó para especificar qual técnica de compactação é utilizada para os pedidos compactados que ele envia. O valor do cabeçalho Content-Encoding é configurado para indicar a compactação que é utilizada. É possível substituir esse valor no ambiente local para uma mensagem individual. Se você substituir o ambiente local por um valor que não é reconhecido pelo nó, o valor do nó existente para Usar Compactação será utilizado.