Inicio / programación

¿Encripta HTTPS también las URLs?

Vale que para el que lo sepa será una tontá de pregunta, pero a mi me ha venido bien saber que:

The entire URL will be encrypted. When the web browser connects to the server, it connects to the appropriate IP address, starts encryption, and then sends the request (hostname, URL, parameters, form contents, etc.).

Note that the DNS lookup will not be encrypted, so anyone looking at your traffic can tell that you looked the domain up, even if they can’t tell what you sent or what came back. This may or may not be important in your case.

Superuser.com

Everything in the HTTP message is encrypted, including the headers, and the request/response load. With the exception of the possible CCA cryptographic attack described in limitations section below, the attacker can only know the fact that a connection is taking place between the two, known to him, parties; the domain name and IP addresses

Wikipedia

Vamos, que si, que primero se resuelve el dominio y una vez establecida la relación de confianza, se envía todo, todito, encriptado.

Ahora… pasar una contraseña en la URL por mucho que vaya encriptada sigue dando respeto como poco.

“Character encoding” una pesadilla recurrente

Hay ciertas cosas que por más que veces que las hayas visto y hecho vuelven a ocurrir una y otra vez… como los problemas con la codificación de caracteres.

UTF-8, ISO-8859-1, Latin-1… son capaces de provocar que tu web, tu aplicación se llene de caracteres chinos (台, 北) y de símbolos raros (æ, Ψ).

Hace poco tuvimos un problema con la prioridad con la que se coge la codificación de una web. ¿Quién manda? ¿El servidor o el cliente?

Pues en W3C lo dejan claro:

To sum up, conforming user agents must observe the following priorities when determining a document’s character encoding (from highest priority to lowest):

  1. An HTTP “charset” parameter in a “Content-Type” field.
  2. A META declaration with “http-equiv” set to “Content-Type” and a value set for “charset”.
  3. The charset attribute set on an element that designates an external resource.

Algunos enlaces que pueden ser de utilidad:

Múltiples IE en tu PC

Con la llegada del infame Internet Explorer 7, ya tenemos otra vez la liada habitual: a ver que se ha roto…

Lo de tener que diseñar para 3 o 4 navegadores con sus distintas versiones, en las diferentes plataformas, sabiendo que ninguno cumple las estándares al 100% es la tí­pica labor que podría hacer cualquier otra persona.

El bueno de Carlos, ha encontrado una pequeña aplicación para poder tener las distintas versiones del Internet Explorer (¡desde IE3!) funcionando en tu ordenador y así ir probando como se comportan tus páginas.

En Install multiple versions of IE on your PC

A ver cuando encontramos algo así­ para Safari…

Librerías Javascript

Cada vez que empiezo a mirar algo sobre Javascript me pasa lo mismo: ¡qué desorden!. Puede que sea algo inexperto en el tema, pero hecho de menos algo de orden, una forma estandarizada de hacer las cosas, un conjunto de librerías coherentes y que se puedan extender fácilmente.

Sin embargo hay varios intentos bastante serios (confieso que no he probado ninguno) y esta es la lista que yo he conseguido:

  • Dojo Toolkit. No sé si es el más serio, o el más completo, pero tiene buena pinta y una base y una forma de hacer bastante buena.
  • Prototype. No tiene mala pinta y parece que ya se usa bastante. Con soporte nativo para Ruby on Rails.
  • Open Rico. Idem, pinta bien, con ejemplos y sencilla de usar.
  • script.aculo.us. Empiezo a odiar esa nomenclatura…, aunque la librerí­a promete.

Otras sugerencias: Behaviour (¿sólo AJAX?), jQuery, mootools.

Algunas de ellas vienen comentadas en: Reliable Designs, en IceBeat y en anieto2k.

Aprovecho y regalo también otro par de enlaces: Nicholas C. Zakas (si sale en los libros de Wrox, algo bueno habrá hecho) y Yahoo UI Library.

Actualización 2006.11.30. Impresionante recopilatorio (como siempre) el de Smashing Magazine: AJAX, DHTML and JavaScript Libraries.

/