Respuestas a las incidencias emitidas a Telefonica por el Tema del Proxy-Cache
escrito por Redacción
martes, 22 abril 2003
1. Actualización de páginas
El servidor de proxy-caché almacena los contenidos visitados para aumentar la rapidez de su presentación en una nueva visita.
Habitualmente, los proveedores de contenido incluyen en sus páginas datos que permiten al proxy-caché averiguar de la forma más óptima la validez o caducidad de un contenido, configurando los servidores Web para que envíen - -en la respuesta HTTP- los criterios de caducidad de dicho contenido e incluso el comportamiento que debe seguir el proxy-caché ante la recepción de dicho contenido.
En caso de que los proveedores no utilicen estos mecanismos en sus contenidos, el usuario puede solicitar la comprobación de la validez de contenidos a través de distintos mecanismos. En concreto, la Red IP de Telefónica de España permite utilizar los mecanismos de comprobación soportados por los navegadores estándar:
Microsoft Internet Explorer. Procedimiento:
Pulsar el botón "Refresh". Esta acción solicita al proxy-caché que compruebe si el contenido ha caducado. Pulsar la tecla "CTRL" y manteniéndola pulsada, usar el botón "Reload" del navegador. Internet Explorer solicitará al proxy-caché que se fuerce el refresco del contenido.
Netscape Navigator:
Procedimiento:
Pulsar el botón "Reload". Esta acción solicita al proxy-caché que compruebe si el contenido ha caducado. Pulsar la tecla "SHIFT" y manteniéndola pulsada, usar el botón "Reload" del navegador. El navegador solicitará al proxy-caché que se fuerce el refresco del contenido.
En el caso de que el navegador utilizado sea otro diferente, se debe comprobar con el fabricante del mismo la posibilidad de realizar acciones equivalentes a las anteriores desde estos navegadores alternativos.
Nota Importante:
En algunas circunstancias de navegación con frames anidados, el navegador no refresca cada uno de los frames visualizados, aunque sí lo hace con los contenidos por defecto dentro del frame más externo.
Los mecanismos antes descritos funcionan gracias a la inclusión en el protocolo estándar HTTP de cabeceras de control de cachés (Cache-Control) en las peticiones de contenido, que permiten esta comunicación relativa a contenidos posiblemente caducados. Para más información, consultar el documento de definición del protocolo HTTP 1.1 (RFC 2616).
2. Uso de resolución de nombres en local.
El cliente realiza la resolución de nombres de forma privada. La resolución de dominios a usar en las peticiones HTTP por puerto 80 deben de ser dominios registrados.
3. Incidencias relativas a cortes en la descarga de páginas.
Existen servidores web en los que algunas peticiones de páginas tienen mucha duración (debido entre otras causas a la posible saturación del propio servidor, ejecución de aplicaciones donde la respuesta tarda?etc.etc), pudiendo tardar hasta 2 minutos en empezar a devolver los contenidos al cliente.
Como consecuencia de la citada duración de tiempo excesivo, la caché temporiza y devuelve al cliente el mensaje de que es imposible satisfacer su petición.
Esto se ha solucionado realizando el tunning de los proxy-cache y aumentando el valor de temporización a 3 minutos. Con esta modificación tales problemas han quedado resueltos.
4. Incidencias en autenticación con NTLM
El sistema de autenticación NTLM de Microsoft no funciona en un entorno de proxy-caché. Este hecho es conocido por Microsoft y, por tanto, sólo recomienda este tipo de autenticación en entornos con conexión punto a punto.
En el entorno de proxy-caché de Telefónica de España, Microsoft recomienda el uso de otros mecanismos de autenticación alternativos a NTLM.
En particular existen casos reportados en Microsoft para las siguientes aplicaciones:
Microsoft Exchange OWA:
http://support.microsoft.com/default.aspx?scid=kb;en-us;198509 Administración de un servidor web autentificado por NTLM: http://support.microsoft.com/default.aspx?scid=kb;en-us;183730
Otros enlaces y recomendaciones sobre métodos de autenticación en diferentes entornos de red aparecen publicados en las siguientes páginas de Microsoft:
No es posible realizar este tipo de autenticación en la Red.
La autenticación por IP origen es algo poco fiable en Internet debido al uso extensivo de IPs dinámicas, proxies, firewalls, etc.... Alternativas como el uso de HTTPS ofrecen una garantía mayor para la seguridad de los servidores web y, por tanto, de la confianza de los usuarios en los mismos.
6. Microcortes en la recepción de streams de audio de WinAMP
Se ha detectado este problema en el SW que implementa la función de caché.
Para resolver esta situación se ha generado una nueva versión de SW que ha sido probada con éxito en los proxy-cache de determinado centro de acceso. Así mismo, se ha comprobado que el parche resuelve los microcortes en la recepción de streams de audio de WinAMP que se distribuyen utilizando el protocolo HTTP (puerto 80).
Actualmente esta nueva versión está siendo implementada en todos los proxy-cache.
7. Incidencia denunciada desde BarraPunto:
"al ir a visitar esta página me encuentro que me han 'baneado'. Bueno. mejor dicho, a mí no, a la IP de mi proxy de salida..."
Literal de la incidencia:
"Pues sí, señores, al fin una muestra de la seguridad prometida por el famoso Proxy-Cache de Timofónica. Según la operadora, el hecho de salir a través de un proxy haría que la navegación fuera más segura, al no mostrar nuestra IP. Pero se olvidaron de decir que el hecho de salir con una única IP para todos podría ocasionar perjuicios como el que me he encontrado al tratar de visitar la página de http://slashdot.org/. Cual ha sido mi sorpresa hoy cuando al ir a visitar esta página me encuentro que me han 'baneado'. Bueno. mejor dicho, a mí no, a la IP de mi proxy de salida..."
Respuesta: El proveedor de destino tenía filtrada la IP 80.58.54.107 de la caché de Burgos Gamonal.
Es responsabilidad suya la política de filtrado de direcciones. Por consiguiente, Telefónica no puede mejorar la citada situación.
8. Incidencias en la Web de "www.entradas.com.
Este sistema utiliza un reparto de carga interno para atender peticiones que se basa en la IP de origen del cliente..
Como solución temporal se le ha aplicado un work-around.
Se ha proporcionado asesoramiento en cuanto a las posibles alternativas a usar para un buen funcionamiento de su sistema de balanceo que mejore el funcionalidad del sistema..
Los problemas de conexión con www.uno-e.com eran debidos a que el propio servidor estaba filtrando las direcciones de los proxy-cache, se advirtió a los administradores de esta circunstancia y eliminaron dicho filtrado.
9.Otro tipo de incidencias al margen de los Proxy-Cache.
Actualmente los protocolos que pasan por caché son HTTP (web) puerto 80 WMT (Streaming de Windows Media) puerto 1755 (UDP y TCP)
Los protocolos que utilizan las aplicaciones de Real Networks, entre ellas la del cliente, RealOne Player, no están siendo cacheados.
Comentario[s]
Sólo los usuarios registrados pueden escribir comentarios. Por favor valídate o regístrate.
Artículos 
