Pseudo-Weblog

HTTP, partie 4.

Je vais éviter de mettre la grammaire de HTTP, mais en la regardant de près, on peut avoir des surprises, commme ma récente decouverte des blancs implicites, en général omise par les serveurs, qui ne sont plus en accord avec la norme. Cependant, il est à noter que les en-têtes sont encodés selon la norme iso-8859-1. Il peut être fait usage d'autres encodages, comme UTF-8, en suivant les règles définies dans la RFC 2047.

Je reviendrai plus tard sur des exemples volontairement tordus (mais valides!) d'en-têtes HTTP. En attendant, regardont les URIs utilisées dans le cadre d'HTTP. Elles sont définies par la RFC 2396, et peuvent être absolues (ex: http://www.example.com/foo/bar), ou relatives (ex: ../toto/titi/tata.txt). Une URI relative se transforme en URI absolue grâce à son contexte, qui est une URI absolue. En utilisant les exemples précédents, on obtient http://www.example.com/toto/titi/tata.txt, le ../ transformant http://www.example.com/foo/ en http://www.example.com/. Un conteneur étant identifié par le / final.

Il est aussi possible d'érire de plusieurs manière une URI, et il y a donc des règles pour s'assurer de l'égalité de deux URIs. C'est une comparaison octet à octet, avec quelques exceptions:

• Le champ "hôte" n'est pas sensible à la casse, ex www.example.com et WWw.ExAmpLE.CoM sont équivalents.
• le schème, lui aussi, n'est pas sensible à la casse, ainsi, http est égal à HTtp.
• Un chemin absolu nul est égal à un /
• Il est possible de remplacer un caractère par son équivalent hexadécimal (dans iso-8859-1). Example: http://www.example.com/foo/bar est égal à hTTp://wWw.Example.COM/%66%6F%6f/b%61r.

La majorité des abus dans les URIs sont dûs à cette variabilité dans l'ecriture, dont le célébrissime ../../ remplacé par ..%2F.. utilisé pour récuperer des fichiers sous la racine du serveur (heureusement, plus aucun serveur n'autorise cela).

à suivre...