Quel codage dois-je utiliser pour l'authentification HTTP basique?

Question

La RFC2617 indique de coder le nom d'utilisateur et le mot de passe en base64 mais ne dit pas quel codage de caractères utiliser lors de la création des octets à saisir dans l'algorithme base64.

Devrais-je assumer US-ASCII ou UTF8? Ou quelqu'un a déjà réglé cette question quelque part?

Answer 1

La spécification peut être lue comme "ISO-8859-1" ou "non définie". Votre choix. Il est connu que de nombreux serveurs utilisent ISO-8859-1 (que cela leur plaise ou non) et échoueront si vous envoyez autre chose.

Pour plus d'informations et une proposition pour remédier à la situation, voir http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.html

Answer 2

Réponse courte: iso-8859-1, à moins codé-mots sont utilisés en conformité avec RFC2047 (MIME).

Une longue explication:

RFC2617, section 2 (Authentification HTTP) définit la base des informations d'identification:

basic-credentials = base64-user-pass
base64-user-pass  = <base64 encoding of user-pass, 
                     except not limited to 76 char/line>
user-pass         = userid ":" password
userid            = *<TEXT excluding ":">
password          = *TEXT

La spécification doit pas être lu sans faire référence à la RFC2616 (HTTP 1.1) pour les définitions de la BNF (comme celle ci-dessus):

Cette spécification est un compagnon de la spécification HTTP/1.1 2. Il utilise le augmented BNF section 2.1 de ce document, et s'appuie sur à la fois les non-terminaux définis dans ce document et d'autres aspects de la spécification HTTP/1.1.

RFC2616 section 2.1 définit le TEXTE (l'emphase est mienne):

Le TEXTE de la règle est utilisée uniquement pour le descriptif contenu du champ et les valeurs qui ne sont pas destinés à être interprétés par le message de l'analyseur. Mots de *le TEXTE PEUT contenir des caractères de jeux de caractères autres que ISO-8859-1 seulement lorsqu'ils sont encodés selon les règles de la RFC 2047.

TEXT           = <any OCTET except CTLs, but including LWS>

Il est donc définitivement iso-8859-1, sauf si vous détectez un autre encodage selon RFC2047 MIME (pt. 3) les règles:

// Username: Mike
// Password T€ST
Mike:=?iso-8859-15?q?T€ST?=

Dans ce cas, le signe de l'euro dans la parole puisse être codé en 0xA4 selon la norme iso-8859-15. C'est ma compréhension que vous devriez vérifier pour ces codé délimiteurs de mots, puis de décoder les mots à l'intérieur basé sur l'encodage spécifié. Si vous ne le faites pas, vous allez penser que le mot de passe est - =?iso-8859-15?q?T¤ST?= (remarquez qu' 0xA4 serait décodé ¤ s'il est interprété comme iso-8859-1).

C'est ma compréhension, je ne peux pas trouver plus de confirmation explicite de ces RFCs. Et certaines d'entre elles paraissent contradictoires. Par exemple, l'un des 4 buts de RFC2047 (MIME, pt. 3) est à redéfinir:

le format des messages pour permettre ... textuelle informations d'en-tête les jeux de caractères autres que US-ASCII.

Mais alors RFC2616 (HTTP 1.1) définit un en-tête à l'aide de la règle de TEXTE qui par défaut est iso-8859-1. Est-ce à dire que chaque mot dans cet en-tête doit être un des mots codés (c'est à dire l' =?...?= formulaire)?

Aussi pertinentes, aucun navigateur ne ce. Ils utiliser l'utf-8 (Chrome, Opera), iso-8859-1 (Safari), le système de code de page (IE) ou autre chose (comme le bit le plus significatif de l'utf-8 dans le cas de Firefox).

Edit: je viens de réaliser cette réponse examine la question de plus à partir du côté serveur, le point de vue.