Hace tiempo me metí con HTTP por ser un protocolo algo vetusto para las necesidades de hoy. Una de las cosas que odiaba especialmente es que cada vez que mi cliente RSS (akregator) mira los feeds, se baja todo el feed nuevamente incluso cuando no había habido cambios. No es un comportamiento muy óptimo: Primero se debería mirar a ver si el documento que el cliente tiene en cache está actualizado, el servidor envia un hash (o algo) en cada documento, el cliente lo almacena, y la próxima vez que vaya a mirar el documento envia o mira el hash de nuevo, y si no ha habido cambios, no se reenvia el documento. Existen problemas reales de servidores que son "atacados" por clientes de rss que se bajan todo el feed cada X tiempo (tanto, que se ha llegado a hablar de que RSS iba a acabar fracasando por no poder aguantar grandes demandas)
Aunque mi falta de pasión por HTTP persiste (sigo pensando que HTTP es perfectamente sustituible por un sistema de archivos remoto bien diseñado e implementado), me he alegrado al saber que HTTP 1.1 si puede hacer aquello de lo que yo me quejaba: Existe la posibilidad de que los clientes almacenen el campo ETag y Last-Modified cuando cogen un documento. Asi, la próxima vez que vayan a mirar ese mismo documento los clientes enviarán esos campos guardados como cabeceras "If-None-Match" e "If-Modified-Since", y el servidor responderá con el código 304, "Not Modified"
Un grep rápido me ha llevado a comprobar que firefox almacena esos campos y más en el cache, y que algunas páginas lo usan y que otras no (las páginas dinámicas parecen no estar muy interesadas en ser cacheadas, por ejemplo). Pero bueno, tan importante es criticar como hacer justicia, y si HTTP a pesar de sus defectos da la talla, la da y es justo reconocerlo. Ahora lo que me importa es conseguir que akregator de la talla y utilize esto para ahorrarme ancho de banda. Ya hay un bug abierto desde hace meses (no muy activo), y parece que KHTML está envuelto en el asunto. Ya se verá
Por si alguien tiene curiosidad, me he enterado de todo esto siguiendo un enlace sobre MSNbot. Parece ser que el bot de msn escanea los feeds con mucha frecuencia haciendo caso omiso de la utilización del conditional get, parece ser que mucha gente bloquea al bot de msn por su mal comportamiento
4 de marzo de 2006
"Conditional GET"
1 de marzo de 2006
cosas que odio de unix, capítulo...
Te pasas años usando cosas hasta que al final te das cuenta de que algo simplemente está mal hecho. Unix tiene muchas cosas mal hechas (creo que ya he escrito bastante sobre ello en este blog) al igual que tiene otras bien. Asi que hoy me toca continuar mi propia tradición
Man. Man es una puta mierda. ¿Por qué las secciones están divididas por números? No se si soy el único, pero jamás he sabido ni quiero saber cual es la sección man correspondiente a la sección de funciones de librerias. Es la 3. Pero a mi no me importa, de verdad. Antes que "man 3 opendir" preferiría algo más lógico, como "man lib opendir", por ejemplo. No entiendo porque me tengo que aprender de memoria una tabla de correspondencias "número -> sección de manual". Es más, no me extrañaría que en alguna de esas certificaciones te obligaran a saberte de memoria algo tan estúpido.
Luego está el tema de los parámetros. Intenta crear un archivo que tenga el mismo nombre que uno de los parámetros. "touch --help". ¿A qué me refiero realmente, a un archivo o a la ayuda? Si, se puede evitar con "touch -- --help", pero esa no es la cuestión. La cuestión es que en Unix, en la linea de comandos típica de bash, los parámetros comparten el mismo espacio de nombres que el sistema de archivos. Y eso no está bien, porque por definición implica que a veces los dos van a "chocar". El "--" es una forma de decir al shell que ignore a las opciones y se centre en los archivos, pero se usa las pocas veces que la gente se encuentra con estos casos en la consola, ¿cuanta gente lo usa en scripts? A todo script al que le pases un parámetro a un ejecutable le puedes pasar "--help", y los resultados son muy divertidos. Me pregunto como podría afectar eso al entramado de scripts y de historias que tenemos en unix, o incluso si se puede utilizar esta falta de comprobación de ciertos parámetros como agujero de seguridad (cosas más raras se han visto en windows)