# WWWOFFLE VERSION 2.6 - PREGUNTAS Y RESPUESTAS PREGUNTADAS FRECUENTEMENTE

Este fichero contiene una lista de las preguntas preguntadas más frecuentemente y sus respuestas en relación con WWWOFFLE 2.6. No todas las preguntas son de usuarios reales, algunas han sido realizadas para dar alguna ayuda a la gente que trata de usar el programa y que encuentra que la documentación del fichero README es insuficiente.

Sección 0 - ¿Por qué este FAQ no responde a mis preguntas?

Sección 1 - Que hace WWWOFFLE (y que no)

Q 1.1 ¿Soporta WWWOFFLE http, ftp, finger, https, gopher, ...?

Q 1.2 ¿WWWOFFLE funciona en otros sistemas aparte de UNIX?

Q 1.3 ¿Puedes cambiar WWWOFFLE para que las páginas que genera ...?

Sección 2 - Como usar WWWOFFLE para servir a una intranet

Q 2.1 ¿Pueden otros clientes aparte de localhost acceder al servidor proxy WWWOFFLE?

Q 2.2 ¿Por qué los clientes remotos no pueden acceder al proxy WWWOFFLE?

Q 2.3 ¿Por qué los clientes remotos no pueden seguir todos los enlaces?

Q 2.4 ¿Cuales son los aspectos de seguridad a tener en cuenta con WWWOFFLE en un entorno multiusuario?

Q 2.5 ¿Cómo puedo tener diferentes configuraciones para diferentes grupos de usuarios?

Sección 3 - Que mirar cuando WWWOFFLE falla

Q 3.1 ¿Por qué mi navegador devuelve una página vacía con WWWOFFLE pero funciona bien sin él?

Q 3.2 ¿Por qué WWWOFFLE no puede encontrar un servidor cuando el navegador sí puede?

Q 3.3 ¿Por qué mi navegador dice "Conexión cortada por el huésped remoto" cuando navego?

Q 3.4 ¿Por qué siguiendo un enlace en un servidor FTP me lleva al servidor incorrecto?

Q 3.5 ¿Por qué WWWOFFLE no maneja las Cookies correctamente?

Q 3.6 ¿Por qué WWWOFFLE vuelver a pedir todas las páginas que se vieron estando desconectado?

Q 3.7 ¿Por qué WWWOFFLE no permite acceder a algunas páginas protegidas con contraseña?

Sección 4 - Manejo de Applets

Q 4.1 ¿Por qué mi navegador no ejecuta el applet XYZ?

Q 4.2 ¿Están soportados los nombres de applets en unicode?

Q 4.3 ¿Por qué mi navegador Netcape saca la excepción de seguridad "trustProxy"?

Sección 5 - Cómo sacar el máximo provecho de las característica de WWWOFFLE

Q 5.1 ¿Cómo puedo ver las páginas monitorizadas que se vieron en la última conexión?

Q 5.2 ¿Cómo puedo hacer una recogida recursiva en un intervalo regular?

Q 5.3 ¿Cómo puedo hacer que los usuarios no puedan acceder al índice?

Q 5.4 ¿Cómo puedo usar Junkbuster con WWWOFFLE?

Q 5.5 ¿Cómo puedo mejorar el rendimiento de WWWOFFLE?

Sección 6 - Más información acerca de WWOFFLE

Q 6.1 ¿Quién escribió WWWOFFLE, Cuando y Por qué?

Q 6.2 ¿Que listas de distribución sobre WWWOFFLE hay disponibles?

Q 6.3 ¿Cómo informo de fallos en WWWOFFLE?

## Sección 0 - Por qué este FAQ no responde a mis preguntas?

Este FAQ se publica con cada nueva versión de WWWOFFLE por lo que si estás leyendo esta versión y la pregunta es una de las que se pregunta frecuentemente acerca de esta versión entonces, por definición, no encontrará la respuesta aquí. Este FAQ está también disponible en la página de WWWOFFLE con mucha más información acerca del programa. http://www.gedanken.demon.co.uk/wwwoffle/version-2.6/

## Sección 1 - Qué hace WWWOFFLE (y que no)

### Q 1.1 ¿Soporta WWWOFFLE http, ftp, finger, https, gopher, ...?

    Algunos de los protocolos están soportados y otros no.

    http : Sí
            La versión original de WWWOFFLE solo soportaba http.

    ftp : Sí
            Desde la versión 2.0 ha habido soporte para URLs ftp.

    finger : Sí
            Desde la versión 2.1 ha habido soporte para finger.  Aunque este no es un
            protocolo estándar para hacer "proxy" no hay ninguna razón para que no se
            pueda realizar satisfactoriamente.

    https : Sí
            Desde la versión 2.4 ha habido soporte transparente para
            conexiones de Capa de Comunicación Segura (SSL).  Esto incluye el protocolo https.

    gopher : No
            Este es un protocolo que es menos popular ahora que la WWW ha despegado.
            Mirando a los navegadores que lo soportan, no parece imposible, pero el
            mercado para ello es muy limitado.

### Q 1.2 ¿WWWOFFLE funciona en otros sistemas aparte de UNIX?

    Por ejemplo DOS / Win3 / Win95 / WinNT / OS/2.

    UNIX    = Sí
            Este es el sistema para el cual fué diseñado en un principio,
            debería funcionar en muchas versiones de UNIX.
            Se que funciona en Linux, SunOS 4.1.x, Solaris 2.x, *BSD.

    DOS/Win3 = No
            El programa no fué diseñado para DOS, los nombres usados y la naturaleza
            multi-proceso del programa no lo permiten.

    Win95/Win98/WinNT = Sí
            Hay disponible una versión Windows de 32-bit del programa gracias al kit de desarrollo
            de Cygwin que provee una librería de llamadas UNIX en MS Windows.

    OS/2    = Quizás
            No sé de un equivalente para el producto de Cygwin para OS/2, si existe
            entonces es posible portarlo como se hizo para Windows 95 /
            Windows NT.

### Q 1.3 ¿Puedes cambiar WWWOFFLE para que las páginas que genera ...?

    Esta es una pregunta que se pregunta a menudo. La gente quiere ver Javascript,
    imágenes, diferentes colores ... en las página web que WWWOFFLE genera.

    Desde la versión 2.2 esto no es un problema ya que es posible cambiar
    todas las páginas web que WWWOFFLE genera.  Esto significa que el color de fondo
    y el tamaño de la fuente pueden ser cambiados para cubrir sus necesidades.
    Para saber como hacer esto mire en el directorio /var/spool/wwwoffle/html/messages
    y lea el fichero README.

## Section 2 - Cómo usar WWWOFFLE para servir una intranet

### Q 2.1 ¿Puede el proxy WWWOFFLE ser accedido por otros clientes aparte de localhost?

    Sí,  puede, esa opción ha estado presente desde el principio.

    Los otros clientes pueden ser cualquier tipo de ordenador conectado al servidor
    que esté ejecutando el programa wwwoffled.  El único requerimiento es que deben estar
    conectados en red con el servidor y que deben tener el navegador configurado para
    acceder al proxy WWWOFFLE.

### Q 2.2 ¿Por qué los clientes remotos no pueden acceder al proxy WWWOFFLE?

    La situación por defecto en el fichero wwwoffle.conf es la de no permitir
    ningún acceso a clientes diferentes de localhost.  Para permitirles el
    acceso al proxy el fichero wwwoffle.conf necesita ser editado como se
    describe abajo y la nueva configuración debe ser cargada.

    La sección AllowedConnect del fichero de configuración contiene una lista de
    servidores que tienen permitida la conexión con el proxy WWWOFFLE.  Estos
    nombres se comprueban contra los nombres que WWWOFFLE encuentra cuando la
    conexión se realiza. De esta forma el acceso es permitido o denegado.  Las
    entradas de la lista pueden contener comodines pero no se realizan
    comprobaciones de nombres extra.

    Por ejemplo si está utilizando el espacio de direcciones IP privadas 192.168.*.* para su intranet
    entonces su sección AllowedConnect en el fichero de configuración debería ser algo como esto.

    AllowedConnect
    {
     192.168.*
    }

    Esto permitirá la conexión al proxy WWWOFFLE a todos los huéspedes que
    vengan de este rango de direcciones IP.

### Q 2.3 ¿Por qué los clientes remotos no pueden seguir todos los enlaces?

    Algunos de los enlaces que son generados en las páginas web que vienen del
    proxy WWWOFFLE necesitan apuntar a otras páginas del proxy.  Para ser capaz
    de hacer esto el nombre del servidor ejecutando el proxy necesita ser
    especificado en la sección LocalHost del fichero de configuración.

    Por ejemplo si el ordenador ejecutando el proxy WWWOFFLE se llama www-proxy
    entonces la sección LocalHost del fichero de configuración sería algo como.

    LocalHost
    {
     www-proxy
     localhost
     127.0.0.1
    }

    El primer de los nombres es el que usará WWWOFFLE para generar los enlaces.
    Los otros son usados por servidores que no son almacenados por el proxy.

### Q 2.4 ¿Cúales son los aspectos de seguridad a tener en cuenta con WWWOFFLE en un entorno multiusuario?

    La seguridad es una aspecto que he estado considerando cuando he escrito
    WWWOFFLE aunque no ha sido una de mis mayores preocupaciones.  Los aspectos
    son los listados abajo.

    Para la versión Win32 se debe anotar que en Win95/98 no hay la seguridad a
    nivel de usuario que provee UNIX.  No es posible crear ficheros que solo
    puedan ser leidos por WWWOFFLE y no por los otros usuarios.  Los aspectos de
    seguridad que están presentes en WWWOFFLE no son, pues, aplicables a estos
    sistemas.

    Contraseña del fichero de configuración
       Este fichero puede tener una contraseña especificada en su sección
       StartUp que se usa para limitar el acceso a las opciones de control
       WWWOFFLE.  Si se activa la contraseña, esta debe ser usada para poner a
       WWWOFFLE Conectado, Desconectado, Purgar la caché, Parar el servidor,
       editar el fichero de configuración etc..  Si tiene puesta una contraseña
       entonces debe hacer que el fichero solo pueda ser leido por los usuarios
       autorizados.  La contraseña se manda como texto plano cuando se usa el
       programa wwwoffle para controlar el servidor wwwoffled.  La encriptación
       usada para la autentificación de la página web no es segura.

    Autentificación del Proxy
       Con la habilidad de controlar el acceso a WWWOFFLE usando el Método de
       Autentificación de Proxy de HTTP/1.1 nos encontramos con sus riegos de
       seguridad añadidos.  Son basicamente los mismos que para la contraseña
       del fichero de configuración, los nombres de usuarios y las contraseñas
       están en texto plano y la contraseña del fichero de configuración que se
       manda al servidor usa el mismo sistema de encriptación inseguro.

    uid/gid del servidor WWWOFFLE
       El uid y el gid del proceso del servidor wwwoffled puede ser controlado
       por las opciones run-uid y run-gid en la sección StartUp del fichero de
       configuración.  Estos uid/gid necesitan poder leer el fichero de
       configuración (la escritura no es requerida a menos que se use la página
       de edición interactiva) y tener acceso de lectura/escritura al directorio
       almacén.  Si se usa esta opción entonces el servidor debe ser comenzado
       por root.

    Borrar URLs pedidas
       Sólo el usuario que realiza una petición de página puede borrar la
       petición, y es entonces cuando el borrado se realiza de forma inmediata.
       Esto es así porque la contraseña se realiza indexando el contenido del
       fichero en el directorio se salidas.  Esto significa que el acceso de
       lectura a este directorio debe ser negado para que sea seguro.

    El servidor web incorporado
       Es un servidor muy simple que seguirá enlaces, como una característica de
       seguridad, solo si los ficheros pueden ser leidos por todo el mundo.
       También deben estar en un directorio que el servidor wwwoffled pueda
       leer.  No se realiza la comprobación para cada directorio por lo que
       ficheros con acceso de lectura para todo el mundo en un directorio que
       solo puede ser leído por el uid que ejecuta wwwoffled no es seguro.

    Accediendo a la caché
       No hay ningún problema general dejando que los usuarios puedan acceder a
       la caché si este es de solo lectura (pero vea URLs con contraseña
       debajo). Lo único de lo que se tiene que preocupar es que la purga se
       realiza usando la hora de acceso de los ficheros, entonces ejecutar grep
       en la caché estropeará la purga.

    URLs con contraseña
       Las URLs que usan usuario y contraseña deben ser almacenadas en la caché.
       Para simplificar no están ocultas de ninguna manera.  Esto significa que
       cualquier URL que use usuario/contraseña puede mostrarse en el fichero
       histórico (con los niveles Debug o ExtraDebug).  Los ficheros en la caché
       también contienen la información usuario/contraseña por lo que no deben
       ser accesibles a los usuarios por esta razón.

### Q 2.5 ¿Cómo puedo tener diferentes configuraciones para distintos grupos de usuarios?

    Cuando hay dos grupos de usuarios que deben acceder a la misma caché de
    WWWOFFLE pero cada grupo debe tener diferentes configuraciones de WWWOFFLE,
    es posible ejecutar dos instancias de WWWOFFLE.

    Por ejemplo, en una escuela puede requerirse que los estudiantes puedan
    acceder a la caché, pero no puedan pedir nuevas páginas. Las profesores
    deben ser capaces de acceder a la misma caché y ser capaces de usar WWWOFFLE
    En Línea y pedir las páginas mientras están Fuera de Línea.

    Las dos configuraciones de WWWOFFLE serán básicamente iguales, pero habrá unas
    cuantas  diferencias como se detalla abajo.

    -- wwwoffle.student.conf --               -- wwwoffle.teacher.conf --
    StartUp                                 | StartUp
    {                                       | {
     http-port     = 8080                   |  http-port     = 9080
     wwwoffle-port = 8081                   |  wwwoffle-port = 9081
     password      = secret                 |  password      = teacher
    }                                       | }
                                            |
    OfflineOptions                          | OfflineOptions
    {                                       | {
     <*://*/*> dont-request = yes           |·
    }                                       | }
                                            |·
    AllowedConnectUsers                     | AllowedConnectUsers
    {                                       | {
                                            |  teacher1:password1
                                            |  teacher2:password2
    }                                       | }
                                            |
    AllowedConnectHosts                     | AllowedConnectHosts
    {                                       | {
                                            |  teacher1pc
                                            |  teacher2pc
    }                                       | }

    Las dos copias de WWWOFFLE deberán usar distintos puertos. Usan el mismo
    directorio de caché y por lo tanto las mismas páginas webs estarán
    disponibles para ambos grupos de usuarios.  Necesitará una contraseña en el
    fichero de configuración de los alumnos para evitar que cambien el fichero,
    pero en el de los profesores puede no ser requerida.  Para evitar que los
    alumnos puedan usar la versión de los profesores debe usar las secciones
    AllowedConnectHosts o AllowedConnectUsers en el fichero de configuración.
    De esta forma se restringirá el acceso a las máquinas a las que tengan
    acceso los profesores o requerirán la introducción de usuario/contraseña
    antes de comenzar la navegación.

    En el ejeplo anterior los alumnos no tienen permitida la petición de páginas
    mientras están desconectados. Esta versión de WWWOFFLE no se usará nunca en
    modo conectado por lo que no hay ninguna forma de que los alumnos puedan
    navegar conectados. Sólo la versión de los profesores podrá ser usada
    estando conectado.

## Section 3 - Que mirar cuando WWWOFFLE falla

### Q 3.1 ¿Por qué mi navegador devuelve una página vacía con WWWOFFLE?

    Cuando se está usando un navegador para visitar una página web no se
    devuelve nada cuando se usa WWWOFFLE como proxy pero cuando el sitio es
    accedido directamente sin WWWOFFLE la página es visible.

    Esto puede deberse a un número de causas (todas se me han reportado o testadas por mi mismo):

    a) El servidor al que esta accediendo requiere la cabecera User-Agent. Si no
       está presente o está puesta a un valor no común (no Netscape o IE) entonces
       devuelve una página vacía.  En este caso si tiene puesto en el fichero de
       configuración que la cabecera CensorHeader quite la cabecera User-Agent
       entonces debe o no censurar esta cabecera o reemplazarla por una cadena que
       sea aceptable.

    b) Como lo descrito arriba, pero no importa el valor de la cadena para
       devolver una página no vacía.  La solución es la misma excepto que se puede
       usar cualquier cadena en la cabecera User-Agent.

    c) El servidor web usa "cookies" para mantener el estado.  Esta es una
       práctica común en sitios que están más preocupados de la forma que del
       contenido, normalmente sin notificación.

    d) El navegador y el servidor tratan de usar las extensiones del protocolo HTTP/1.1 que WWWOFFLE ignora.

### Q 3.2 ¿Por qué WWWOFFLE no puede encontrar un servidor cuando el navegador sí puede?

    La razón más posible es que el servidor DNS que se configuró antes de
    ejecutar WWWOFFLE ya no sea válido.  Esto podría pasar por ejemplo si el
    fichero /etc/resolv.conf cambió después de que se ejecutara wwwofled.  Este
    no es un problema sólo de WWWOFFLE ya que afecta a (la mayoría) de los
    programas que usan el DNS.

    Cuando WWWOFFLE mira un nombre de servidor usa la función de la librería
    estándar de UNIX (libc) gethosbyname().  La parte de la libc(llamada
    librería de resolución) es inicializada cuando el programa usa una función
    de esa parte por primera vez.  Cuando más tarde se ejecuta una de las funciones
    de esta librería usará la configuración que había cuando se ejecuta la
    primera vez.

    La configuración de DNS puede cambiar sin que usted se de cuenta.  Algunos
    de los programas amistosos al usuario cambian el fichero /etc/resolv.conf
    dependiendo de a que ISP se conecte. Un ejemplo de programa que hace esto es
    kppp.

    Los proyectos de grandes navegadores (Netscape en particular) pueden usar
    otros métodos para la resolución de nombre aparte de los de la librería
    estándar.  Esto significa que pueden funcionar aunque la configuración de
    DNS haya cambiado desde que se ejecutó.  Si funciona Netscape y no funciona
    WWWOFFLE significa que su servidor de nombres a cambiado y que no es un
    error de WWWOFFLE.

    Se ha sugerido varias veces que cambie WWWOFFLE para que llame a la función
    res_init() cada vez que pase a modo conectado.  Esta es la función que se
    llama la primera vez que se hace una resolución DNS.  Inicializa la librería
    de resolución de DNS.

    Tengo las siguientes objeciones a esto.  No hay nada que diga que llamar a
    res_init() más de una vez es seguro en todos los sistemas, que llamar a
    res_init() más de una vez funcione en todos los sistemas o que llamar a
    res_init() más de una vez seguirá funcionando en futuras versiones de la
    librería de resolución.

    La función res_init() es una función de muy bajo nivel que no está diseñada
    para ser usada desde un programa. Está diseñada para inicializar la librería
    de resolución y en ningún sitio de los que he visto dice que es seguro
    llamarla más de una vez o que pueda ser usada para cambiar el método de
    resolución DNS.

    Una solución es ejecutar un servidor de nombres local.  El paquete bind
    contiene el servidor de nombres estándar pero hay alternativas.  Una opción
    es pnsd que es un servidor DNS de caché.  Para cualquier opción que elija
    necesitará usar su máquina como el servidor de nombres y cambiar la
    configuración de DNS cada vez que se conecte.

### Q 3.3 ¿Por qué mi navegador dice "Conexión Cortada por el Servidor Remoto" cuando navego?

    Esto pasa cuando se usa Netscape para acceder a algunas páginas web.  La
    causa no se conoce, pero el problema sólo se ve cuando se usa WWWOFFLE y no
    cuando se hace una conexión directa.

### Q 3.4 ¿Por qué siguiendo un enlace en un servidor FTP me lleva al servidor incorrecto?

    Si hay un directorio llamado '/dir' en un servidor ftp server y carga la página
    'ftp://servidor/' se obtiene una lista de directorios que incluye un enlace a '/dir'.
    Si sigue este enlace le llevará a 'ftp://server/dir/', pero en algunos navegadores va
    a 'ftp://dir/' en vez de al anterior.

    Creo que este comportamiento es debido al navegador y no a WWWOFFLE.  Si usted fue
    a 'http://server/' y siguió el enlace a '/dir/' usted esperaria ir
    a 'http://server/dir/' y no a 'http://dir/'.  Esto es de sentido común.
    No estoy seguro de porqué el navegador hace diferencias entre ftp y http.

    [Esto debe estar arreglado en la versión 2.1 de WWWOFFLE, por lo que no es
    aplicable a esta versión del FAQ]

### Q 3.5 ¿Por qué WWWOFFLE no maneja las Cookies correctamente?

    Los proxys normales no pueden almacenar el resultado de URLs con Cookies ya
    que el resultado es diferente para cada usuario.  WWWOFFLE las almacenará
    porque está diseñado para reducir el tráfico de red.

    Si usa cookies cuando esté navegando las páginas que vea no serán iguales
    cuando las vea desconectado.  La mejor forma de manejar este caso para un
    sitio en particular es poniendolo en la sección DontCache del fichero de
    configuración.

    WWWOFFLE no es capaz de almacenar páginas que usen cookies para el control
    de contenido de la misma forma que almacena las páginas que no usan cookies.
    Cualquier implementación del manejo de cookies necesita diferentes
    respuestas a los usuarios dependiendo de la cookie que haya en la petición.
    Para hacer esto se necesitaría guardar diferentes páginas para la misma URL.

    Hay un problema cuando se va a una página A que pone una cookie y
    dependiendo de esta la página B da una página diferente.  Por ejemplo, si
    tiene una cookie y tiene la página B en la caché. Cuando está desconectado
    si sigue el enlace de B a A puede darle otra nueva cookie desde A (cuando se
    conecte y recoja A).  Esto signifa que no puede ir para atrás desde B ya que
    las cookies son diferentes (y también la página, pero no la tiene
    almacenada).

    Un problema peor es que al recargar la página C con la misma cookie le da
    una página diferente cada vez.  Esto es así porque la cookie se usa para
    contar el número de veces que ha visitado la página.  No hay forma de saber
    esto y por lo tanto obtendrá la misma página C (la almacenada) incluso si
    debería obtener diferentes.

### Q 3.6 ¿Por qué WWWOFFLE vuelver a pedir todas las páginas que se vieron estando desconectado?

    Puede pasar cuando está desconectado y hojea las páginas a través de WWWOFFLE
    que las páginas son pedidas de nuevo aunque esten ya en la caché de
    WWWOFFLE.  Hay dos posibles causas para que suceda esto.

    1) Cuando elije un marcapáginas desde Netscape (y posiblemente otros
       navegadores) se hace una nueva petición para la página marcada.

    2) Algunos usuarios han informado de que al usar Netscape algunas páginas
       hojeadas son pedidas de nuevo.  (No todos los usuarios experimentan este
       comportamiento y no se ha encontrado una razón de porqué algunas personas lo
       lo sufren y otras no.)

    En ambos casos el navegador está enviando una petición que le dice a
    WWWOFFLE que necesita una nueva versión de la página.  Es la misma que la
    opción de forzar la recarga que la mayoría de los navegadores ofrecen.
    Se envia una cabecera con la petición a todos los proxys entre el navegador
    y el servidor para que se pida una nueva versión de la página y que las
    versiones almacenadas deberían ser ignoradas.

    Para desactivar esta acción en WWWOFFLE hay una opción llamada
    'pragma-no-cache' que por defecto es 'sí'.  Cuando esta opción se activa la
    peticiones para recargar la versión de la página forzará que se pida otra
    versión.  Si la descactiva con la opción 'no' acabará con los dos tipos de
    comportamientos descritos arriba.

### Q 3.7 ¿Por qué WWWOFFLE no permite acceder a algunas páginas protegidas con contraseña?

    Cuando un navegador pide una página que tiene asociados un usuario y
    una contraseña se comienza un diálogo entre el navegador y el servidor para
    mostrar la página correcta.

    1) Cuando un navegador pide una página protegida por contraseña se realiza una
       petición sin la contraseña.  Esto es obvio ya que no hay ninguna forma de
       saber que páginas tienen contraseña.

    2) Cuando el servidor recive una petición por la página que requiere
       autentificación pero no lleva ninguna contraseña devuelve una respuesta
       '401 No autorizado'. Esta contiene un "reino" que define el rango
       de página sobre las cuales este par usuario/contraseña es válido.
       Un reino no es un rango bien definido. Puede ser cualquier conjunto de
       páginas en el mismo servidor. No tienen porqué tener relación entre sí,
       aunque normalmente la tienen.

    3) Cuando un navegador recive una respuesta '401' preguntará al usuario por
       un usuario y contraseña si no tiene una especificado para el reino actual.
       Si ya se conoce una no es necesario molestar al usuario de nuevo.

    4) La petición que el navegador devuelve esta vez incluye en la cabecera el
       para nombre de usuario y la contraseña o si no la misma petición que en
       el caso (1).

    5) El servidor manda de vuelta la página pedida.

    WWWOFFLE tiene características para hacerlo más fácil para el usuario.  Muchos
    navegadores, por ejemplo, saltarán directamente al paso 4 de la lista si
    saben que ya hay una contraseña para una de las páginas del servidor.  Esto
    significa que no hay nada en la caché de WWWOFFLE que le indique al
    navegador que necesita un nombre de usuario y contraseña cuando un usuario
    intenta ver una página protegida con contraseña estando desconectado.
    WWWOFFLE sólo preguntará un usuario y contraseña si se almacena la página
    resultante del paso 2 en la caché.

    Cuando se pide una página y tiene un usuario y contraseña en la petición
    WWWOFFLE primero intentará pedir la página sin usuario y contraseña.  Esto
    es así para que no se salte el paso 1 aunque el navegador lo intente.  Si la
    página no requiere cntraseña la versión de la página sin contraseña se
    enviará al navegador.  Si se necesita contraseña WWWOFFLE hará otra segunda
    petición con un usuario y contraseña y enviar el resultado al navegador.

    Algunos servidores ha llevado esto más allá y espera que los usuarios envien
    la contraseña para cada página.  Si se hace una petición sin contraseña el
    navegador es redirigido a la página de de entrada.  El caso especial de
    WWWOFFLE descrito arriba no funciona en esta situaciones.

    Para desactivar esta característica en WWWOFFLE hay una opción
    'try-without-password' que por defecto es 'sí'.  Cuando esta opción está
    activada las peticiones de una página con contraseña forzará a WWWOFFLE a
    hacer la petición sin contraseña.  Poniendo esta opción a 'no' desactivará
    esta característica.

## Section 4 - Manejo de Applets

### Q 4.1 ¿Por qué mi navegador no ejecuta el applet XYZ.

    [Walter Pfannenmueller <pfn@online.de> escribe:]

    Supongo que ha puesto en marcha el soporte de java.  Su navegador dice algo
    así como "No puedo ejecutar el Applet XYZ.class".  Mire a ver si
    el fichero ha sido correctamente bajado por WWWOFFLE.  Si el fichero es
    accesible, abra una consola java (su navegador debe tener algo parecido) y
    lea más detalles sobre el problema.  Problablemente es una violación de
    seguridad.  Todos los navegadores tienes su propio Administrador de
    Seguridad y debe consultar el manual para ver como pueden rebajar estas
    restricciones.  Si su applet intenta entrar en contacto con alguna función
    del servidor (servlets, RMI, CORBA), hemos llegado al final de las
    posibilidades de un lector en modo desconectado.

### Q 4.2 ¿Están soportados los nombres de applet en unicode.

    [Walter Pfannenmueller <pfn@online.de> escribe:]

    No lo sé.  Yo transformo estos nombres a codificación UTF8  y el resto
    depende de los que haga con él su sistema de ficheros o el sistema de
    ficheros del servidor.  Los compiladores de Java también tienen problemas
    con unicode, aunque sebería estar soportado.  Apreciaría cualquier
    información que ayude a esclarecer la oscuridad.  Me gustaría saber como
    programar tranformaciones de Unicode a UTF8.  La implementación en
    javaclass.c parece un poco enrevesada.

### Q 4.3 ¿Por qué mi navegador Netcape saca la excepción de seguridad "trustProxy"?

    [Walter Pfannenmueller <pfn@online.de> escribe:]

    El mensaje de error debería ser

    No es posible resolver la IP del servidor ... Mire la propiedad trustProxy.

    El navegador Netscape intenta verificar la IP del húesped del código fuente
    del applet.  Minetras de está Fuera de Línea esto no es posible. Por lo
    tanto debe persuadir al navegador de que confie en el proxy.  Para hacer
    esto debe encontrar el fichero de preferencias preferences.js en UNIX o
    prefs.js en Windows. Edite el fichero, aunque diga "No editar" u
    agrege la siguiente línea user_pref("security.lower_java_network_security_by_trusting_proxies",
    true);

    Asegúrese de haber cerrado todas las ventanas del navegador, porque el
    fichero de preferencia será sobreescrito al salir. Esto debería bastar para
    todos los Netscape 4.0x y 4.5.  Para más información eche un vistazo en
    http://developer.netscape.com/docs/technote/security/sectn3.html

## Sección 5 - Cómo sacar el máximo provecho de las característica de WWWOFFL

### Q 5.1 ¿Cómo puedo ver las páginas monitorizadas que se vieron la última desconexión?

    La forma más fácil de hacer esto es yendo al índice de páginas monitorizadas
    y ordenar las páginas por "Hora de Acceso"
    (http://localhost:8080/index/monitor/?atime). Cada página será accedida
    cuando sea monitorizada por lo que las más recientes serán las que esten al
    principio de la lista.

### Q 5.2 ¿Cómo puedo hacer una recogida recursiva en un intervalo regular?

    Esto es una combinación de la opción de recogida recursiva y la opción de
    monitor.  Si selecciona la página que quiera en el índice de recogida
    recursiva (http://localhost:8080/refresh-options/) con las opciones que
    quiera y pulsa el botón, se le presentará una página diciéndole que su
    petición se ha grabado.  Hay un enlace hallí que le permitirá monitorizar
    esta petición, que le llevará a la página normal del monitor
    (http://localhost:8080/monitor-options) pero con la URL ya llena.

### Q 5.3 ¿Cómo puedo hacer que los usuarios no puedan acceder al indice?

    El control a los índices puede ser denegado a los usuarios usando la sección
    del fichero de configuración DontGet.

    DontGet
    {
     http://localhost:8080/index
    }

    Debe asegurarse de que el nombre del servidor que ponga es el primero en la sección
    LocalHost porque este es el nombre que se comprobará.

### Q 5.4 ¿Cómo puedo usar Junkbuster con WWWOFFLE?

    El Cazador de Basura de Internet(Junkbuster) es un programa que puede filtrar los
    anuncios y otras carácterísticas de las páginas web.

    Las versiones más recientes de WWWOFFLE añaden muchas de las características
    de JunkBuster, pero no todas ellas.  Si mira a las opciones que
    WWWOFFLE tiene, puede decidir que no necesita Junkbuster.
    Si decide que quiere usar los dos programas tiene dos opciones:

    1) Navegador <-> WWWOFFLE <-> JunkBuster <-> Internet

    Todas las páginas que los usuarios pidan y que JunkBuster bloquee tendrán los mensajes
    de error almacenados en la caché de WWWOFFLE.  Cualquier recogida simple o recursiva
    de imágenes que realice WWWOFFLE en segundo plano pasan a través de JunkBuster y los
    mensaje de error de JunkBuster serán almacenados.

    2) Navegador <-> JunkBuster <-> WWWOFFLE <-> Internet

    Cualquier página que el usuario pida y que Junkbuster bloquee no se
    almacenarán en la caché de WWWOFFLE.  Cualquier búsqueda simple o recursiva
    de imágenes que realice WWWOFFLE en segundo plano no pasará a través de
    JunkBuster y no se almacenará en la caché de WWWOFFLE pero será bloqueada
    cuando el navegador trate de verlas.

    Si decide que WWWOFFLE hará muchas recogidas pero está usando el navegador estando desconectado
    entonces el primer método es el mejor. Si decide que solo usará el navegador conectado
    y que no pedirá páginas desconectado entonces el segundo método es mejor.

    Si la más importante característica de JunkBuster es la de reducir ancho de banda
    entonces el primer método es el mejor, ya que impedirá que WWWOFFLE recoja
    las páginas basura.

### Q 5.5 ¿Cómo puedo mejorar el rendimiento de WWWOFFLE?

    Puede hace una serie de cambios en WWWOFFLE dependiendo de lo que esté
    intentanto mejorar.

    1) Si quiere servir las página almacenadas por WWWOFFLE más rápido.

    El programa WWWOFFLE necesita almacenar la página web que almacena en disco.
    Este es el punto que debe mejorar para aumentar el rendimiento y hace que
    corra más.

    La primero que hay que hacer es aumentar el rendimiento del disco físico que
    está usando como caché.  Esto significa que puede hacer lo siguiente: Un
    disco más rápido. Usar otra partición en un disco separado de otros discos
    muy usados o poner el disco en una controladora IDE que no esté compartida
    con otros discos.

    Lo siguiente que puede intentar hacer es mejorar el rendimiento de la
    interfaz del sistema operativo con el hardware.  Esto se puede hacer o
    seleccionando correctamente el controlador para el hardware que use o
    afinando los parámetros del controlador de disco (p.e. usando hdparm en
    Linux).

    Otra cosa que debe comprobar es el sistema de ficheros que esté usando.
    Algunos sistemas operativos permiten elegir el sistema de ficheros a usar en
    la partición de disco.  En Linux, por ejemplo, si usa Reiserfs en vez de
    ext2fs mejorará el rendimiento de WWWOFFLE debido a un mejor manejo de
    directorios grandes.  También puede haber opciones de montaje del disco que
    puedan mejorar el rendimiento.

    En Linux por ejemplo es posible cambiar el tamaño de los búfers que el
    núcleo usa como caché de disco haciendo lo siguiente:

    echo 25 30 75 > /proc/sys/vm/buffermem
    echo 10 10 65 > /proc/sys/vm/pagecache

    Esto incrementa la cantidad de memoria que se reserva como caché de ficheros
    y el máximo permitido.

    Otro cambio que debe hacer es optimizar el fichero de configuración.  Hay
    otras muchas cosas que hacer. Algunas tienen desventajas de algún tipo.
    Reducir el número de entradas en la sección DonGet reducirá el tiempo
    perdido en buscar la URL que se pidió. Use comodines si es posible.
    Dessactivando las modificaciones de HTML y GIFs animados (La sección
    ModifyHTML).  Reduzca la edad máxima en la sección Purge para usar una caché
    más pequeña.

    2) Si quiere usar WWWOFFLE para reducir el ancho de banda de la red.

    Una característica de WWWOFFLE que atrae a muchos usuarios es la abilidad
    para reducir el ancho de banda de la red.  Esto se purde lograr de diferentes
    formas. Bajando la frecuencia a la que se piden páginas 'estáticas',
    guardando más páginas en la caché, bloqueando anuncios o ignorando peticiones
    a servidores para no recargar la misma página una y otra vez.

    Las páginas estáticas que pueden ser almacenadas por mucho tiempo son las
    imágenes.  Estas pueden ser los iconos que aparecen en casi todas las
    páginas del mismo servidor.  Estas se pueden guardar en la caché de WWWOFFLE
    durante mucho tiempo y no son vueltas a pedir porque raramente cambian.
    El siguiente ejemplo muestra como se puede configurar para reducir el ancho
    de banda de un conjunto de páginas estáticas en particular (Estas opciones
    específicas de la URL necesitan ir antes de las opciones genéricas).

    OnlineOptions
    {
     <http://images*.slashdot.org> request-changed = 4w
     <http://*slashdot.org> request-changed-once = yes
    }

    Purge
    {
     <http://images*.slashdot.org> age = 6w
     <http://*slashdot.org> age = 4w
    }

    Puede almacenar más páginas en la caché incrementando la 'edad' en la
    sección Purge del fichero de configuración.  Esto se puede aplicar a todas
    las páginas o selectivamente a los sitios que se visitan más a menudo.

    La sección DontGet del fichero de configuración tiene muchas ventajas para
    reducir el ancho de banda de la red al bloquear objetos que no desea ver.
    Estos puede ser, por ejemplo, anuncios o contadores.

    Otra caracterísitca que algunos servidores Web consideran útil es la opción
    para forzar la recarga de una misma página.  Esto puede realizarse de
    diferentes formas. Si usa las opciones 'request-changed' o
    'request-changed-once' en la sección OnlineOptions WWWOFFLE no hará otra
    petición de la página hasta que esta haya llegado a una determinada edad.
    Las opciones 'request-expired' y 'request-no-cache' pueden ponerse a 'no'
    para que las páginas que han expirado no sean pedidas de nuevo.

## Section 6 - Más información acerca de WWWOFFLE

### Q 6.1 ¿Quién escribió WWWOFFLE, Cuando y Por qué?

    El programa WWWOFFLE fue escrito por Andrew M. Bishop (amb@gedanken.demon.co.uk)
    en 1996,97,98.

    Hay una página web de WWWOFFLE accesible desde la página web del autor en
    http://www.gedanken.demon.co.uk/.
    Es actualizada con noticias acerca del programa, cada vez que sale una
    nueva versión.

    La versión anterior del programa escrita por el mismo autor en perl fué
    usada por un tiempo pero se dió cuenta de que la funcionalidad de la versión
    era insuficiente excepto para un uso reducido.  El trabajo en el programa
    WWWOFFLE en si mismo enpezó en las vacaciones de Navidad de 1996.
    Inicialmente era un apaño para mejorar la versión en perl.

    Después de la liberación de la versión Beta 0.9 a comienzo de Enero de 1997
    se generó mucho interés, lo que condujo a la liberación de la version 1.0
    más tarde ese mismo mes.  Hasta Diciembre de aquel año le siguieron más
    versiones hasta que la versión 2.0 fue liberada.  Esta contenía nuevas
    características (como FTP) e incluía una reescritura de gran parte del
    código para hacerlo más fácil de mantener y mejorar, Esto incluyó cambiar
    completamente el formato de la caché.  La versión 2.1 fue liberada en Marzo
    de 1998 con algunas nuevas características, la versión 2.2 en Junio de 1998
    con más características y la versión 2.3 en Agosto de 1998 con todavía más
    características.

    La versión Win32 del programa fue posible gracias a la versión beta-20 del
    Kit de desarrollo de Cygwin a finales de Octubre de 1998 cuando la versión
    2.3e de WWWOFFLE fue liberada.

    El programa WWWOFFLE pruede ser distribuido libremente de acuerdo a los
    términos de la Licencia Pública General GNU (GPL) (vea el fichero
    `COPYING').

### Q 6.2 ¿Qué listas de correo sobre WWWOFFLE hay disponibles?

    Ahora hay 2 listas de correo disponibles para WWWOFFLE.  Se puede suscribir de dos formas diferentes - en la página web de usuarios de WWWOFFLE y via correo electrónico.

    wwwoffle-announce       Para anuncios de nuevas versiones de WWWOFFLE.

    wwwoffle-users          Para discutir de características de WWWOFFLE,
                            excluyendo características específicas del sistema operativo.

    La dos primeraas son solamente para anuncios del autor de WWWOFFLE, no está
    permitido discutir en ellas.  En las dos siguientes pueden publicar
    los miembros de la lista y otros que no están suscritos.

    To join one of these mailing lists send an e-mail to one of
    wwwoffle-announce-request@gedanken.demon.co.uk or
    wwwoffle-user-request@gedanken.demon.co.uk with the subject 'subscribe'.

### Q 6.3 ¿Cómo informo de fallos en WWWOFFLE?

    Por correo electrónico, mandemelos a amb@gedanken.demon.co.uk y ponga
    WWWOFFLE en algún lugar de la línea de tema.  Puede tambien reportar fallos
    o hacer comentariosor desde el formulario en la pagina web de WWWOFFLE
    situada en http://www.gedanken.demon.co.uk/.

    Antes de hacer esto, debería comprobar la FAQ y la página web de WWWOFFLE
    para ver si la respuesta esta allí.  Si no está y quiere informar de ello
    no lvide que ayuda si usted puede reproducir el error, en particular arrancar
    wwwoffle con las opciones de depurado activadas.

    Si usa sh/bash como shell ejecute

    wwwoffled -d 5 -c wwwoffle.conf > wwwoffled.log 2>&1

    Si usa csh/tcsh como shell ejecute

    wwwoffled -d 5 -c wwwoffle.conf >& wwwoffled.log

    Si necesita más información de depurado use '-d 6' en ves de '-d 5'