Gestionar el proceso de peticiones

Cuando Caching Proxy recibe la petición de un cliente, realiza la acción especificada en el campo de método del objeto especificado del campo URL, si se ha habilitado el método solicitado. El servidor proxy resuelve el URL de acuerdo con un conjunto de normas de correlación definidas por el administrador. Es posible que estas normas de correlación indiquen a Caching Proxy que actúe como un servidor Web y recupere el objeto del sistema de archivos local o que actúe como un servidor proxy y recupere el objeto de un servidor de origen.

En este se describe cómo habilitar los métodos, definir las normas de correlación y configurar un servidor proxy sustituto.

Habilitación de métodos HTTP/FTP

Las peticiones de cliente dirigidas al servidor incluyen un campo de método que indica la acción que el servidor va a realizar en el objeto especificado.

A continuación aparece una lista de métodos a los que el servidor proxy da soporte y una descripción de cómo responde a una petición que contenga el método cuando éste está habilitado.

Nota:
Algunos métodos son los mismos que para HTTP y para las peticiones FTP. La habilitación de estos métodos para HTTP también los habilita para FTP.

CONNECT
El método CONNECT permite transmitir a través del túnel las peticiones y respuestas mediante el servidor proxy. Sólo se aplica a configuraciones de proxy de reenvío.

Para obtener información sobre el formato y las opciones disponibles para el método Enable CONNECT, consulte Configuración de túneles SSL.

DELETE
El servidor proxy suprime el objeto identificado por el URL. DELETE permite a los clientes borrar los archivos de Caching Proxy. Utilice las configuraciones de protección de servidor para definir quién puede utilizar DELETE y en qué archivos. Para obtener más detalles, consulte Configuraciones de protección del servidor.
GET
El servidor proxy devuelve cualquier dato identificado por el URL. Si el URL hace referencia a un programa ejecutable, el proxy devuelve la salida del programa. Este método se puede manejar a través de conexiones persistentes.
HEAD
El servidor proxy sólo devuelve la cabecera del documento HTTP identificada por el URL sin el cuerpo del documento.
OPTIONS
El servidor proxy devuelve información sobre las opciones de comunicaciones de la cadena de petición-respuesta identificada por el URL. Este método permite que un cliente determine las opciones y requisitos asociados con un objeto o las posibilidades de un servidor sin necesidad de actuar sobre el objeto o recuperarlo.
POST
La petición contiene datos y un URL. El servidor proxy acepta los datos contenidos en la petición como un nuevo subordinado del recurso identificado en el URL, que procesa los datos. El recurso puede ser un programa que acepte datos, una pasarela de algún otro protocolo o un programa independiente que acepte anotaciones.

El método POST se designa para manejar la anotación de recursos existentes. Entre los ejemplos se incluye el envío de un mensaje a un tablón de anuncios, un grupo de noticias o lista de correo, o recursos de grupo similares; el paso de un bloque de datos, por ejemplo, de un formulario a un programa de manejo de datos, o la ampliación de una base de datos a través de una operación añadir. En Caching Proxy, el método POST se utiliza para procesar los formularios de Configuración y Administración.

Este método se puede manejar a través de conexiones persistentes.

PUT
La petición contiene datos y un URL. El servidor proxy almacena los datos en el recurso identificado en el URL. Si el recurso ya existe, PUT lo sustituye con los datos contenidos en la petición. Si el recurso no existe, PUT lo crea y lo llena con los datos contenidos en la petición. Este método se puede manejar a través de conexiones persistentes.

La habilitación del método PUT permite que los archivos se escriban en Caching Proxy mediante HTTP y FTP. Como PUT permite a los clientes escribir en Caching Proxy, es necesario que utilice las configuraciones de protección de servidor para definir quién puede utilizar PUT y los archivos en los que se puede utilizar PUT. (Consulte el Configuraciones de protección del servidor.)

TRACE
El servidor proxy repite el mensaje de petición enviado al cliente. Este método permite que el cliente vea lo que se está recibiendo en el otro extremo de la cadena de petición y utilice esos datos para realizar operaciones de diagnóstico o pruebas. El tipo de contenido de la respuesta del proxy es message/http.

Directivas asociadas

Las siguientes directivas habilitan los métodos HTTP/FTP:

Para obtener más información, consulte Edición manual del archivo ibmproxy.conf.

Formularios de Configuración y Administración

Los siguientes formularios de Configuración y Administración editan los valores de las directivas asociadas:

Nota:
Si inhabilita el método POST, no puede utilizar los formularios de Configuración y Administración para configurar el Caching Proxy.

Para obtener más información, consulte el Utilización de los formularios de Configuración y Administración.

Habilitar métodos WebDAV, métodos MS Exchange y métodos definidos por el usuario

Sólo se aplica a configuraciones de proxy de retorno.

Además del soporte de métodos HTTP estándar, Caching Proxy da soporte al reenvío de otros métodos definidos en los RFC o utilizados por algunas aplicaciones. Caching Proxy también da soporte a métodos definidos por el cliente y permite reenviarlos mediante el servidor proxy.

WebDAV (Web-based Distributed Authoring and Versioning) es un conjunto de extensiones del protocolo HTTP que permite editar y gestionar archivos de forma cooperativa en servidores Web remotos. Caching Proxy da soporte a los métodos WebDAV, métodos utilizados por Microsoft Exchange Server y métodos definidos por el usuario (personalizados).

Estos métodos están codificados y se gestionan con las directivas Enable y Disable. Los administradores también pueden utilizar la máscara de método definida en la directiva PROTECT para autorizar el uso de estos métodos.

Métodos WebDAV soportados (RFC 2518): PROPFIND , PROPPATCH , MKCOL, COPY, MOVE, LOCK, UNLOCK, SEARCH

Métodos de MS Exchange soportados: BMOVE, BCOPY, BDELETE, BPROPFIND, BPROPPATCH, POLL, NOTIFY, SUBSCRIBE, UNSUBSCRIBE, ACL, SUBSCRIPTIONS, X_MS_ENUMATTS

Cuando los métodos WebDAV o de MS Exchange Server están habilitados, Caching Proxy sólo reenvía las peticiones a los servidores de destino y no reescribe ningún enlace de recurso en el cuerpo de las peticiones.

Caching Proxy también puede reenviar métodos definidos por el usuario al servidor de fondo. Utilice la sintaxis siguientes para la directiva Enable en el archivo ibmproxy.conf a fin de habilitar un método personalizado:

Enable   método-definido-por-usuario [WithBody | WithoutBody]

Establecer el valor WithBody o WithoutBody indica al proxy si el método definido por el usuario necesita un cuerpo de petición.

El siguiente ejemplo habilita un método definido por el usuario My_METHOD e indica al proxy que el método necesita un cuerpo de petición:

Enable MY_METHOD WithBody

Directivas asociadas

Las siguientes directivas habilitan los métodos WebDAV, métodos de MS Exchange y métodos definidos por el usuario:

Para obtener más información, consulte Edición manual del archivo ibmproxy.conf.

Definición de normas de correlación

Las normas de correlación son directivas de configuración que hacen que las peticiones de cliente dirigidas a Caching Proxy se procesen de algún modo, por ejemplo, se pasan a un servidor de origen (proxy), se redirigen o se rechazan. Es importante establecer las normas de correlación correctamente para el correcto funcionamiento del Caching Proxy. Las normas de correlación tienen un efecto sobre lo siguiente:

Las directivas de normas de correlación utilizan el siguiente formulario:

norma plantilla destino [dirección_IP |
nombre_sistppal]:[puerto]

Sólo las peticiones que coinciden con la combinación determinada de plantilla y puerto IP están sujetas a esta regla. Una plantilla puede contener comodines, por ejemplo, https://**/*.asp.

El orden en el que aparecen las normas en el archivo de configuración es significativo. Excepto las directivas Map, tan pronto como la petición coincide con una plantilla, aquella se procesa y no se evalúan las normas posteriores. La directiva Map sustituye el URL de la petición. Esta nueva petición continúa para ser comparada con las restantes normas de correlación.

Normas de correlación

Las siguientes normas de correlación se aplican a las peticiones de cliente que coinciden con la plantilla determina:

La siguiente norma de correlación se aplica a la respuesta de servidor de origen:

Las siguientes normas de correlación se aplican a las aplicaciones API:

Configuración del servidor sustituto

Para configurar un sustituto estándar:

Esto permite que todo el tráfico HTTP del puerto 80 pase por el proxy al servidor de origen. El tráfico que entre en el puerto de administración no coincide con la norma de proxy comodín inicial y, por lo tanto, no se ve afectado. Las restantes normas de correlación se utilizan para procesar la petición.

Directivas asociadas

Las siguientes directivas definen las normas de correlación:

Para obtener más información, consulte Edición manual del archivo ibmproxy.conf.

Formularios de Configuración y Administración

El siguiente formulario de Configuración y Administración edita los valores de las directivas asociadas:

Nota:
Los formularios de Configuración y Administración no dan soporte al argumento de número de puerto.

Para obtener más información, consulte el Utilización de los formularios de Configuración y Administración.

Habilitación de la reescritura de unión (opcional)

Sólo se aplica a configuraciones de proxy de retorno.

La directiva JunctionRewrite habilita la rutina de reescritura de unión en Caching Proxy para reescribir las respuestas de los servidores de origen para garantizar que los URL relativos al servidor se correlaciones correctamente con el servidor de origen correcto cuando se utilizan uniones. El plug-in de reescritura de unión también debe habilitarse. Las uniones se definen mediante normas de correlación del proxy.

Al utilizar las normas de correlación del proxy para definir la unión, puede utilizar la directiva Proxy con la opción JunctionPrefix o sin ella.

Definición de la unión sin la opción JunctionPrefix

A continuación se ofrecen ejemplos de uniones válidas sobre las que puede actuar la rutina de reescritura de unión:

A continuación se ofrece un ejemplo de una unión válida sobre la que no actuará la rutina de reescritura de unión:

A continuación aparecen ejemplos de uniones no válidas:

Estas normas de correlación han creado uniones para servidortienda, servidorautoriz y servidorb2b. Considere que servidortienda devuelve un documento HTML con los siguientes URL contenidos en los distintivos HTML apropiados:

La rutina de reescritura de unión reescribirá las referencias relativas al servidor mediante las normas de correlación del proxy del modo siguiente:

Definición de la unión con la opción JunctionPrefix (método recomendado)

Al utilizar la opción JunctionPrefix con la directiva Proxy, en lugar de inferir JunctionPrefix del primer patrón de URL de la norma Proxy, puede declarar el prefijo de unión de la norma Proxy mediante el formato siguiente:

Proxy url_patern1 url_pattern2 JunctionPrefix:url_prefix

Al utilizar JunctionPrefix, no hay límites en cuanto al formato del primer patrón de URL. Para dar soporte a la reescritura de unión cuando no se utilice la opción JunctionPrefix, el URL de proxy debe tener el siguiente formato: Proxy /market/* http://servidorautoriz/*. Sin embargo, al utilizar JunctionPrefix, la siguiente norma Proxy es válida para la reescritura de unión:

Proxy  /market/partners/*.html http://servidorautoriz.acme.com/*.html
       junctionprefix:/market/partners

La rutina de reescritura de unión afecta a los siguientes distintivos:

Tabla 3. Distintivos afectados por la rutina de reescritura de unión
Distintivo Atributos
!— URL
a href
applet archive, codebase
area href
base href
body background
del cite
embed pluginspage
form action
input src
frame src, longdesc
iframe src, longdesc
ilayer src, background
img src, usemap, lowsrc, longdesc, dynsrc
layer src, background
link href
meta url
object data, classid, codebase, codepage
script src
table background
td background
th background
tr background
Nota:
La rutina de reescritura de unión no afectará a los distintivos generados por JavaScript o los plug-ins del explorador.

Directivas asociadas

Las siguientes directivas se utilizan para habilitar el plug-in y la rutina de reescritura de unión.

Para obtener más información, consulte Edición manual del archivo ibmproxy.conf.

Formularios de Configuración y Administración

Los siguientes formularios deConfiguración y Administración se pueden utilizar para habilitar el plug-ins de reescritura de unión:

Nota:
Los formularios de Configuración y Administración no dan soporte a la directiva JunctionRewrite.

Para obtener más información, consulte el Utilización de los formularios de Configuración y Administración.

UseCookie como alternativa a JunctionRewrite

Puede utilizar cookies para almacenar información del servidor de programa de fondo del siguiente modo: se envía una cookie al navegador de cliente. Cuando el navegador envía peticiones a los recursos de la página HTML, éste adjunta una cookie de modo que Caching Proxy envía las peticiones al servidor de programa de fondo correcto.

Para utilizar cookies como una alternativa para JunctionRewrite, efectúe las siguientes modificaciones en el archivo ibmproxy.conf:

  1. Modifique JunctionRewrite on con JunctionRewrite on UseCookie.
  2. Comente el plug-in JunctionRewrite.

A continuación aparece una comparación entre el plug-in JunctionRewrite y la implementación de cookies.

Ejemplo de plug-in de transformación rápida para ampliar la funcionalidad de JunctionRewrite

Se proporciona código de ejemplo personalizable que reescribe y analiza los bloques de distintivos JavaScript™ (SCRIPT) y applet (APPLET) de los archivos HTML. El plug-in JunctionRewrite por sí solo puede procesar los enlaces de recursos en JavaScript o en los valores de parámetros de Java™.

Después de instalar Caching Proxy, puede compilar el mismo código y configurarlo para que se ejecute con JunctionRewrite.

Loa siguientes archivos de ejemplo están situados en el subdirectorio ...samples/cp/, bajo el directorio en que ha descargado el fixpack.