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 tema se describe cómo habilitar los métodos, definir las normas de correlación y configurar un servidor proxy sustituto.
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.
Para obtener información sobre el formato y las opciones disponibles para el método Enable CONNECT, consulte Configuración de túneles SSL.
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.
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.)
Las siguientes directivas habilitan los métodos HTTP/FTP:
Para obtener más información consulte el Edición manual del archivo ibmproxy.conf.
Los siguientes formularios de Configuración y Administración editan los valores de las directivas asociadas:
Para obtener más información, consulte el Utilización de los formularios de Configuración y Administración.
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
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 el Edición manual del archivo ibmproxy.conf.
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.
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:
Para configurar un sustituto estándar:
Port 80
Proxy /* http://nuestro.servidor.contenido.com/* :80
AdminPort 8080
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.
Las siguientes directivas definen las normas de correlación:
Para obtener más información consulte el Edición manual del archivo ibmproxy.conf.
El siguiente formulario de Configuración y Administración edita los valores de las directivas asociadas:
Para obtener más información, consulte el Utilización de los formularios de Configuración y Administración.
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.
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:
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:
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 |
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 el Edición manual del archivo ibmproxy.conf.
Los siguientes formularios deConfiguración y Administración se pueden utilizar para habilitar el plug-ins de reescritura de unión:
Para obtener más información, consulte el Utilización de los formularios de Configuración y Administración.
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:
A continuación aparece una comparación entre el plug-in JunctionRewrite y la implementación de cookies.
Proxy /no-juntion.jpg http://login-server/no-junction.jpg
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.