Apêndice B. Sintaxe de Regra de Conteúdo (Padrão)

Este apêndice descreve como usar a sintaxe (padrão) de regra de conteúdo para o método de encaminhamento cbr do componente CBR e do componente Dispatcher, junto com cenários e exemplos de seu uso.

Sintaxe (Padrão) de Regra de Conteúdo:

Aplicável apenas se você selecionou "conteúdo" para o tipo de regra.

Insira a sintaxe padrão que deseja usar com as seguintes restrições

Palavras-chave Reservadas

Palavras-chave reservadas são sempre seguidas por um sinal de igual "=".

Method
Método de HTTP na solicitação, por exemplo, GET, POST, entre outros
URI
Caminho para a solicitação da URL (com distinção entre maiúsculas e minúsculas)
Version
Versão específica da solicitação, HTTP/1.0 ou HTTP/1.1
Host
Valor do host: cabeçalho (sem distinção entre maiúsculas e minúsculas)
Nota:
Opcional em protocolos HTTP/1.0
<key>
Qualquer nome de cabeçalho HTTP válido que o Dispatcher pode procurar. Exemplos de cabeçalhos HTTP são User-Agent, Connection, Referer, entre outros

Um navegador dirigindo-se a http://www.company.com/path/webpage.htm pode resultar em valores como:

Method=GET
URI=/path/webpage.htm
Version=HTTP/1.1
Host=www.company.com
Connection=Keep-Alive
Referer=http://www.company.com/path/parentwebpage.htm
Nota:
O shell do sistema operacional pode interpretar caracteres especiais, como "&", e convertê-los em texto alternativo antes de cbrcontrol avaliá-los. Se você estiver inserindo o comando a partir de dscontrol, cbrcontrol ou de um arquivo de configuração, use aspas duplas (" ") ao redor dos caracteres especiais.

Por exemplo, o comando a seguir só é válido com o uso do prompt cbrcontrol>> ou a partir de um arquivo de configuração:

rule add 10.1.203.4:80:cbr_prod_rule_ek type content
  pattern "uri=/nipoek/*"

Ao usar caracteres especiais, para que esse mesmo comando funcione no prompt do sistema operacional, você deverá colocar aspas duplas ao redor do comando inteiro:

cbrcontrol "rule add 10.1.203.4:80:cbr_prod_rule_ek type content
  pattern uri=/nipoek/*"

Se as aspas não forem usadas, alguns padrões podem ficar truncados quando a regra for salva no CBR.

A seguir está uma coleção de possíveis cenários e exemplos para o uso de sintaxes padrão

Cenário 1:

A configuração de um nome de cluster envolve um conjunto de servidores da Web para conteúdo HTML padrão, outro conjunto de servidores da Web com WebSphere Application Server para solicitações do servlet, outro conjunto de servidores Lotus Notes para arquivos NSF, entre outros. O acesso aos dados de cliente é obrigatório para a distinção entre as páginas solicitadas. Também é necessário enviá-los aos servidores apropriados. As regras de correspondência de padrão de conteúdo fornecem a separação necessária para a realização dessas tarefas. Uma série de regras é configurada para que a separação necessária das solicitações ocorra automaticamente. Por exemplo, os comandos a seguir realizam as três divisões mencionadas:

>>rule add cluster1:80:servlets type content pattern "uri=*/servlet/*" priority 1
>>rule uses cluster1:80:servlets server1+server2
>>rule add cluster1:80:notes type content pattern "uri=*.nsf*" priority 2
>>rule uses cluster1:80:notes server3+server4
>>rule add cluster1:80:regular type true priority 3
>>rule uses cluster1:80:regular server5+server6

Se uma solicitação para o arquivo NSF chegar ao Balanceador de Carga, a regra dos servlets será verificada primeiro, mas não será correspondente. A solicitação então é verificada pela regra do Notes e retorna uma correspondência. O cliente tem a carga balanceada entre server3 e server4.

Cenário 2

Outro cenário comum é quando o Web site principal controla diversos grupos internos distintos. Por exemplo, www.company.com/software envolve um conjunto diferente de servidores e conteúdo da divisão www.company.com/hardware. Como todas as solicitações são baseadas no cluster www.company.com raiz, as regras de conteúdo devem localizar diferenças de URI e concluir o balanceamento de carga. A regra do cenário é semelhante à seguinte:

>>rule add cluster1:80:div1 type content pattern "uri=/software/*" priority 1
>>rule uses cluster1:80:div1 server1+server2
>>rule add cluster1:80:div2 type content pattern "uri=/hardware/*" priority 2
>>rule uses cluster1:80:div2 server3+server4

Cenário 3

Certas combinações são sensíveis à ordem em que as regras são procuradas. Por exemplo, no Cenário 2, clientes eram divididos com base em um diretório no caminho da solicitação; no entanto, o diretório de destino pode aparecer em diversos níveis do caminho e significar coisas diferentes no posicionamento. Por exemplo, www.company.com/pcs/fixes/software é um destino diferente de www.company.com/mainframe/fixes/software. As regras devem ser definidas para serem consideradas para essa possibilidade e não capturarem muitos cenários ao mesmo tempo. Por exemplo, o teste "uri=*/software/*" é muito amplo para uma procura de caracteres curinga nesse caso. Regras alternativas podem ser estruturadas da seguinte maneira:

Uma procura de combinação pode limitar isto:

>>rule add cluster1:80:pcs type content pattern "(uri=/pcs/*)&(uri=*/software/*)"
>>rule uses cluster 1:80:pcs server1

Em casos em que não há combinações a serem usadas, a ordem se torna importante:

>>rule add cluster1:80:pc1 type content pattern "uri=/pcs/*"
>>rule uses cluster1:80:pc1 server2

A segunda regra é capturada quando "pcs" aparece em marcas de diretório posteriores em vez de na primeira.

>>rule add cluster1:80:pc2 type content pattern "uri=/*/pcs/*"
>>rule uses cluster1:80:pc2 server3

Em quase todos os casos, você quer completar as regras com uma regra sempre true padrão para capturar tudo que for reprovado em outras regras. Isso também pode ser um servidor "O site está atualmente inativo. Tente novamente mais tarde." para cenários em que todos os outros servidores falham para esse cliente.

>>rule add cluster1:80:sorry type true priority 100
>>rule uses cluster1:80:sorry server5