les caractères autorisés dans les en-tête HTTP valeurs?

Après des études de HTTP/1.1, plus précisément à la page 31 et liées je suis venu à la conclusion que toutes les 8 bits de l'octet peut être présent dans l'en-tête HTTP de la valeur. I. e. tout caractère de code à partir de [0,255].

Et pourtant les serveurs HTTP, j'ai essayé de refuser de prendre quoi que ce soit avec le code > 127 (ou plus US-ASCII non imprimables caractères).

Ici est séchée, extrait de la grammaire utilisée dans la norme:

message-header = field-name ":" [ field-value ]
field-name     = token
field-value    = *( field-content | LWS )
field-content  = <the OCTETs making up the field-value and consisting of
                  either *TEXT or combinations of token, separators, and
                  quoted-string>

CR             = <US-ASCII CR, carriage return (13)>
LF             = <US-ASCII LF, linefeed (10)>
SP             = <US-ASCII SP, space (32)>
HT             = <US-ASCII HT, horizontal-tab (9)>
CRLF           = CR LF
LWS            = [CRLF] 1*( SP | HT )
OCTET          = <any 8-bit sequence of data>
CHAR           = <any US-ASCII character (octets 0 - 127)>
CTL            = <any US-ASCII control character (octets 0 - 31) and DEL (127)>
TEXT           = <any OCTET except CTLs, but including LWS>

token          = 1*<any CHAR except CTLs or separators>
separators     = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\"
               | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT

quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext         = <any TEXT except <">>
quoted-pair    = "\" CHAR

Comme vous pouvez le voir field-content peut être un quoted-string, qui est un enquoted séquence de TEXT (c'est à dire toutes les 8 bits de l'octet à l'exception de " et les valeurs de [0-8, 11-12, 14-31, 127] gamme) ou quoted-pair (\ suivie par une valeur allant de [0, 127] gamme). I. e. tout 8 bits char séquence peut être transmis par fr-le citant et en préfixant les symboles spéciaux avec \).

(À noter que la norme ne permet pas de traiter NUL(0x00) char spéciale)

Mais, de toute évidence, soit tous les serveurs que j'ai essayé ne sont pas conformes ou norme a changé depuis 1999 ou je ne peux pas le lire correctement.

Alors... quels sont les caractères autorisés dans l'en-tête HTTP valeurs et pourquoi?

P. S. la Raison derrière tout cela: je suis à la recherche d'un moyen de passer codé en utf-8 de la séquence d'en-tête HTTP de la valeur (sans autre encodage, si possible).

On dirait que personne a vraiment de la présente partie de la norme au sérieux. J'ai fini par tout simplement les url-encodage valeurs d'en-tête.
Notez que separators dans field-names doivent être encodés. Aussi, si vous utilisez WinHTTP -- vous devrez encoder apostrophe symbole dans field-name, ou à la demande échoue.
Conseil: la RFC 2616 est totalement hors de propos. Reportez-vous à RFC 7230.
Je ne savais pas à propos de la RFC 7230. Est-il un fonctionnaire standard HTTP/1.1? (demander, car greenbytes lien pointe vers un document portant la mention "projet de NORME")
RFC 7230 ne pas réécrire la RFC 2616 - il clarifed heureusement. [tools.ietf.org/html/rfc7230#section-3.2] (§3.2) utilise le jeton VCHAR pour spécifier la limite permise de champ-contenu; VCHAR est défini dans [tools.ietf.org/html/rfc7230#section-1.2] (§1.2), comme visible USASCII caractère. Cela clarifie jeton élimine le besoin de passer du temps à l'abattage des non-caractères visibles comme le RFC 2616, mais ne pas étendre la 1999/1982 définition pour inclure de 128 à 255. L'OP question est "quels sont les caractères autorisés dans l'en-tête HTTP valeurs et pourquoi". J'ai répondu que, avec les références.

OriginalL'auteur C.M. | 2017-12-07

  1. 5

    RFC 2616 est obsolète (voir https://www.rfc-editor.org/info/rfc2616), la partie concernée a été remplacée par la RFC 7230 (voir https://www.greenbytes.de/tech/webdav/rfc7230.html#rfc.section.A.2.p.9):

    L'octet NUL n'est plus autorisé dans les commentaires et quoted-string texte,
    et la manipulation de l'anti-slash-sauvant dans les a été clarifié. L'
    cité de la paire de règle n'est plus permet d'échapper les caractères de contrôle autres
    que HTAB. Non US-ASCII contenu dans les champs d'en-tête et l'expression de motif
    a été rendu obsolète et rendues opaques (le TEXTE de la règle a été supprimée).
    (Section 3.2.6)

    En essence, la RFC 2616, par défaut ISO-8859-1, et ce fut à la fois insuffisante et non interopérables, de toute façon. Ainsi, RFC 7230 a retiré de non-ASCII octets dans le champ des valeurs. La recommandation est d'utiliser un échappement mécanisme sur le dessus de celui-ci tel que défini dans la RFC 8187, ou plaine URI de un pour cent de l'encodage).

    Est la RFC 2616 obsolète? Oui. Ne fait que répondre à l'OP de la question de savoir "quels sont les caractères autorisés dans l'en-tête HTTP valeurs et pourquoi"? Pas de.
    Les caractères Non-ASCII sont obsolètes. Vous pouvez les envoyer, mais il n'y a aucune garantie que le destinataire à faire ce que vous attendez. C'est ce que la spec dit, et c'est la réponse 🙂
    J'ai enfin réussi à lire la RFC 7230. Je ne vois pas de "obsoletion" de la non-US-ASCII contenu dans p3.2.6 - il paraît qu'elle permet à tout 0x80-0xFF char dans quoted-string. 0x00-0x7F gamme a obtenu décimé. I. e. selon cette norme, vous pouvez transmettre des données utf-8, en-tête valeur tant que vous échapper "interdit" de 0x00-0x7F gamme. Suis-je tort?
    field-name peut contenir ' trop... je pense que ce cas particulier devra rester dans mon code si je me soucie de MS serveurs web.
    "En tant que convention, ABNF la règle des noms préfixés par "l'obs-" dénoter "obsolètes" les règles de grammaire qui apparaissent pour des raisons historiques." - greenbytes.de/tech/webdav/rfc7230.html#rfc.section.1.2.p.3

    OriginalL'auteur Julian Reschke

  2. -1

    Il semble que si il ya une erreur dans le HTTP/1.1 spécifications. Comme vous l'avez souligné, §4.2 décrit le contenu du champ comme OCTET:

    field-content = les OCTETs qui composent le champ de la valeur

    Et OCTET est défini dans le §2.2:

    OCTET = 8 bits de la séquence de données

    Ces lignes sont à la base de votre conclusion que les octets > 127 devrait être autorisé, et certainement je vois comment vous avez tiré cette conclusion. La mention de l'OCTET dans le §4.2 est l'erreur trompeur; il doit être de type CHAR.

    Si vous lisez le paragraphe 4.2 (en-Têtes de Message) depuis le début, vous remarquerez les conseils suivants:

    HTTP champs d'en-tête...suivre le même format générique que celle qui est donnée dans la Section 3.1 de la norme RFC 822

    Si nous le faisons en suivant les instructions et aller à RFC 822, spécialement §3.1.2 (Structure de champs d'en-tête), nous apprenons ceci:

    Le champ nom doit être composé de caractères ASCII imprimables
    (c'est à dire, les personnages qui ont des valeurs entre 33. et 126.,
    virgule, à l'exception du côlon). Le terrain du corps peut être composé de n'importe quel
    Les caractères ASCII    , à l'exception de CR ou LF.

    Ainsi, alors que HTTP/1.1 a été écrit en 1999, ils ont utilisé une définition de 1982 à décrire le contenu d'un champ. En 1982, les caractères de 0 à 127 ont été appelés "ASCII" et de 128 à 255 ont été appelés "ASCII Étendu". Maintenant, dans cette réponse, je ne vais pas à s'impliquer dans la bataille de nourriture qui obtient évoqué lors de l'utilisation du terme "ASCII Étendu". Je vais simplement vous au §3.3 de la RFC 822 pour la définition de ce qu'était puis considéré comme "n'importe quel caractère ASCII":

    CHAR = n'importe quel caractère ASCII ( Octal: 0-177, les Décimales: 0.-127.)

    Et donc là vous l'avez - the smoking gun. "ASCII" arrêté à 127 en 1982. Les écrits de l'alinéa partie de la RFC 2616 §4.2 points dans la bonne direction, et le malheureux plus tard, la mauvaise utilisation du jeton d'OCTET dans la même section qui vous a amené vers le bas ce trou de lapin.

    Cette interprétation est erronée, voir en particulier <greenbytes.de/tech/webdav/rfc2616.html#rfc.section.2.2.p.4>.
    Je suis d'accord avec Geek Stocks qu'il y a une carence ou d'une fausse déclaration dans la RFC 2616. Mais @JulianReschke semble être correct, il semble qu'il y a une tentative consciente d'inclure des caractères non-ASCII. Je suppose que la norme a été écrit par plusieurs personnes avec des points de vue différents sur le sujet?
    Il est pas mal. (1) En 1999, la RFC 2616 défini le contenu sous la forme décimale 0...127 et l'abattage de la non-visible de gamme — qui est incontestable et j'ai montré que. (2) RFC 7230 ne pas développer les caractères autorisés pour inclure les non-visible ASCII > 127. Votre lien est juste une copie de la RFC 2616.
    vous tirez une conclusion erronée. La RFC 2616 en effet permis à des caractères non-ASCII. RFC 7230 a déconseillé en raison pour les raisons que j'ai évoquées (et je devrais le savoir, je suis l'un des auteurs). "suit le format" est une explication, si le format d'origine; ce n'est pas une référence normative.
    Dans la RFC 2616, l'ABNF pour "TEXTE" est "<tout OCTET à l'exception des Ctl, mais y compris LWS>". OCTET est défini comme "<toute séquence 8-bit de données>". En outre, la RFC 2616 très clairement dit: "les Paroles de *le TEXTE PEUT contenir des caractères de jeux de caractères autres que l'ISO-8859-1 [22] seulement lorsqu'ils sont encodés selon les règles de la RFC 2047 [14]." - si les caractères de l'ISO-8859-1 (qui est un super jeu de US-ASCII) être utilisée dans le TEXTE. Je pense que c'est assez clair. La référence à l'US-ASCII s'applique à l'ABNF de règles qui disent "US-ASCII", pas d'OCTET.

    OriginalL'auteur Geek Stocks