Fix typos

Author: gianu

es/06.1.md

@@ -2,17 +2,17 @@
 
 Las sesiones y cookies son dos conceptos muy comunes en la web, y también son muy malentendidos. Sin embargo, son extremadamente importantes para la autorización de páginas, así como para tener información para estadísticas de las páginas. Echémos un vistazo a los dos siguientes casos de uso.
 
-Supón que quieres acceder a una página que tiene acceso restringido al público, como el perfil de twitter de un usuario. Por supuesto que puedes abrir tu navegador y escribir tu usuario y contraseña para acceder a esa información, pero el concepto de "exploración web" significa  usar un programa para automatizzar este proceso sin intervención humana. Por consiguiente, tenemos que encontrar que está ocurriendo realmente detrás de bambailnas cuando vamos a usar un navegador para acceder.
+Supón que quieres acceder a una página que tiene acceso restringido al público, como el perfil de twitter de un usuario. Por supuesto que puedes abrir tu navegador y escribir tu usuario y contraseña para acceder a esa información, pero el concepto de "exploración web" significa  usar un programa para automatizar este proceso sin intervención humana. Por consiguiente, tenemos que encontrar que está ocurriendo realmente detrás de bambalinas cuando vamos a usar un navegador para acceder.
 
-Cuando por primera vez recibimos una página de acceso y escribimos un usuario y contraseña, después de presionar el botor de "entrar", el navegador envía una petición POST a un servidor remoto. El servidor redirecciona al usuario a su página de inicio después de verificar la información de acceso y retorna una respuesta HTTP. La pregunta aquí es ¿cómo el servidor sabe quien tiene privilegios de acceso a cierta página? Como HTTP es sin estado el servidor no tiene cómo saber si se ha pasado la verificación en el paso anterior. La solución mas fácil en ingenua es pegar el nombre de usuario y la contraseña en la URL. esto funciona, pero coloca mucha presión en el servidor, porque siempre se debe validar un usuario y una contraseña en la base de datos, y puede hacer que la experiencia de usuario se deteriore. Una alternativa para lograr esta meta es guardar la identidad del usuario en el cliente y el servidor usando cookies y sesiones.
+Cuando por primera vez recibimos una página de acceso y escribimos un usuario y contraseña, después de presionar el botor de "entrar", el navegador envía una petición POST a un servidor remoto. El servidor redirecciona al usuario a su página de inicio después de verificar la información de acceso y retorna una respuesta HTTP. La pregunta aquí es ¿cómo el servidor sabe quien tiene privilegios de acceso a cierta página? Como HTTP es sin estado, el servidor no tiene cómo saber si se ha pasado la verificación en el paso anterior. La solución mas fácil e ingenua es pegar el nombre de usuario y la contraseña en la URL. esto funciona, pero coloca mucha presión en el servidor, porque siempre se debe validar un usuario y una contraseña en la base de datos, y puede hacer que la experiencia de usuario se deteriore. Una alternativa para lograr esta meta es guardar la identidad del usuario en el cliente y el servidor usando cookies y sesiones.
 
 Las cookies, de una manera corta, almacenan información (incluyendo la información de acceso) en el computador del cliente. El navegador envía estas cookies cada vez que el usuario visita el mismo sitio, automáticamente completando el paso de acceso para el usuario.
 
 ![](images/6.1.cookie2.png?raw=true)
 
 Figure 6.1 principio de las cookies.
 
-Las sesiones, por otro lado, guardan información histórica en el lado del servidor. El servidor utiliza un identificador de sesión para diferenciar las esiones, y también este identificador es generado por el servidor y debería ser aleatorio y único. Puedes utilizar cookies o argumentos en la URL para obtener la identidad del cliente.
+Las sesiones, por otro lado, guardan información histórica en el lado del servidor. El servidor utiliza un identificador de sesión para diferenciar las sesiones, y también este identificador es generado por el servidor y debería ser aleatorio y único. Puedes utilizar cookies o argumentos en la URL para obtener la identidad del cliente.
 
 ![](images/6.1.session.png?raw=true)
 
@@ -30,7 +30,7 @@ Las cookies tiene un tiempo de expiración, y se dividen en dos tipos por su cic
 
 Si tu aplicación no le da a una cookie un tiempo de expiración, el navegador no la guardará en el sistema de almacenamiento después de que el navegador sea cerrado. Estas cookies son llamadas cookies de sesión y son guardadas usualmente en memoria en vez del sistema de almacenamiento permanente.
 
-Si tu aplicación define un tiempo de expiración (por ejemplo, setMaxAge(60*60*24)), el navegador *guardará* esta cookie en el sistema de ficheros, y no la elimninará hasta que se alcance el tiempo de expiración. Las cookies guardadas en el sistema de ficheros pueden ser accedidas por diferentes instancias del navegador, por ejemplo, por dos ventanas de Internet Explorer; diferentes navegadores usan diferentes procesos para manejar las cookies que son guardadas en memoria.
+Si tu aplicación define un tiempo de expiración (por ejemplo, setMaxAge(60 * 60 * 24)), el navegador *guardará* esta cookie en el sistema de ficheros, y no la elimninará hasta que se alcance el tiempo de expiración. Las cookies guardadas en el sistema de ficheros pueden ser accedidas por diferentes instancias del navegador, por ejemplo, por dos ventanas de Internet Explorer; diferentes navegadores usan diferentes procesos para manejar las cookies que son guardadas en memoria.
 
 ## Definir cookies en Go
 
@@ -86,7 +86,7 @@ Una sesión es una serie de acciones o mensajes. Por ejemplo, piensa en las acci
 
 Las sesiones ayudan a almacenar el estado de la conexión entre servidor y cliente, y esto puede ser en forma de estructuras de datos.
 
-Las sesiones son mecanismos del lado del servidor y usualmente empleaan tablas has (o algo similar) para guardar la información que llega.
+Las sesiones son mecanismos del lado del servidor y usualmente emplean tablas hash (o algo similar) para guardar la información que llega.
 
 Cuando una aplicación necesita asignar una nueva sesión a un cliente, el servidor debe verificar si existen sesiones anteriores del actual cliente con un único identificador de sesión. Si la sesión ya existe, el servidor continúa con la misma sesión al cliente. Por otro lado, si una sesión no existe para el cliente, el servidor crea una nueva sesión (estu usualmente ocurre cuando el servidor ha eliminado el identificador de sesión correspondiente, pero el usuario ha usado la sesión anterior manualmente).
 

es/06.2.md

@@ -7,7 +7,7 @@ En la sección 6.1, aprendimos que las sesiones son soluciones para la verificac
 El principio básico detrás de las sesiones es que el servidor mantiene la información de cada cliente , y los clientes tienen una única sesión para acceder a su información. Cuando los usuarios visitan la aplicación web, el servidor crea una sesión siguiendo los siguientes pasos en tanto sean necesarios:
 
 - Crear un identificador de sesión único.
-- Abrir un espacio de almacenamiento: normalmente tenemos las sesiones en memoria, pero las perderás si el sistema accidentalmente se interrumpe. Esto puede ser un serio problema si la aplicación web maneja datos sensibles, como de comercio electrónico por ejemplo. Para solucionar este problema, puedes guardar los datos de sesión en la base de datos o en el sistema de ficheros. Eso hace que los datos sean mas fiables y fácil de compartir con otras aplicaciones, sin embargo la negociaciónde información es mas del lado del servidor para leer y escribir sesiones.
+- Abrir un espacio de almacenamiento: normalmente tenemos las sesiones en memoria, pero las perderás si el sistema accidentalmente se interrumpe. Esto puede ser un serio problema si la aplicación web maneja datos sensibles, como de comercio electrónico por ejemplo. Para solucionar este problema, puedes guardar los datos de sesión en la base de datos o en el sistema de ficheros. Eso hace que los datos sean mas fiables y fácil de compartir con otras aplicaciones, sin embargo la negociación de información es mas del lado del servidor para leer y escribir sesiones.
 - Enviar el identificador de sesión único al cliente.
 
 El paso clave aquí es enviar un identificador único de sesión al cliente. En el contexto de una respuesta HTTP estándar, puedes usar el encabezado o el cuerpo que lo acompaña, por consiguiente, tenemos dos maneras de enviar identificadores de sesión a los clientes: por cookies o por URLs.