Comment interpréter vide en-tête HTTP Accept?

HTTP/1.1 Accept en-tête de requête est spécifié dans La RFC 2616, l'article 14.1.

C'est la syntaxe est donnée comme ceci:

   Accept         = "Accept" ":"
                    #( media-range [ accept-params ] )

# sans états zéro ou plus selon la section 2.1. Toutefois, l'article 14.1 ne fait aucune déclaration au sujet de la façon d'interpréter un vide Accept en-tête. Ceci est en contraste à l'article 14.2, qui parle de Accept-Encoding, où non seulement 1# est utilisé (un ou plusieurs), mais aussi le cas pour un vide Accept-Encoding en-tête est spécifiée, qui est une sorte de bizarre. Certains autres sections portant sur les en-têtes de demande sont également spécifiques sur le cas particulier d'une valeur vide.

Doit-on traiter un vide Accept en-tête de manière équivalente à un inexistante Accept en-tête? Existe-il des ressources officielles sur ce que j'ai manqué?

InformationsquelleAutor Jonas Schäfer | 2012-08-26
  1. 22

    De RFC2616 Sec4.2:

    Chaque champ d'en-tête se compose d'un nom suivi d'un deux-points (":") et la valeur du champ.

    À première vue, cela semble pour mettre les messages qui spécifient vide de valeurs d'en-tête dans le mal formé, non-conformes à la catégorie. Cependant, l'augmentation de la BNF forme décrite dans RFC2616 Sec2.1 indique que

    "#element" permet à n'importe quel nombre, y compris zéro

    Que c'est la déclaration utilisé pour spécifier l'en-tête Accept valeurs, il apparaît que les valeurs vides sont valides.

    Analyse de vide en-têtes et les en-têtes avec rien mais des espaces peut être problématique en raison de la direction suivante à partir de la spécification:

    Le champ à contenu ne comprend pas tout leader ou suiveur LWS: linéaire
    l'espace blanc, survenus avant le premier caractère non-blanc de la
    champ valeur, ou après le dernier caractère non-blanc de la
    champ valeur. De plus en plus important de début ou de fin LWS PEUVENT être enlevés sans
    la modification de la sémantique de la valeur du champ. Tout LWS qui se produit entre
    le terrain de contenu PEUVENT être remplacés par un seul SP avant d'interpréter la
    valeur de champ ou de transférer le message en aval.

    À mon humble avis, l'envoi d'un vide-tête est complètement inutile. Il ne devrait pas être fait, et les analyseurs ne peut pas analyser correctement ces en-têtes. Traditionnellement, les gens qui veulent contourner ces limitations lorsque vous traitez avec des pièces non conformes avez spécifié "pseudo-vide" valeurs comme ceci:

    X-MyCustomHeader: ""

    Si vous voulez tout simplement pour vérifier si un champ d'en-tête a été envoyé comme une certaine forme de commutateur booléen, envisager l'envoi d'une valeur de l'espace réservé comme ci-dessus au lieu d'une valeur vide.

    Mise à jour

    Je suppose que je n'étais pas très clair à répondre directement à la question: dans le cas d'un vide-tête Accept-vous vraiment avez deux options:

    • Envoyer un 406 Not Acceptable réponse à informer le client que vous n'offrez pas les types de contenu pour un vide Accepter la valeur (duh).

    C'est justifié, mais pas exigée par RFC2616 Sec14.1:

    Si un en-tête Accept champ est présent, et si le serveur ne peut pas envoyer un
    la réponse qui est acceptable selon les combinés Accepter champ
    valeur, puis le serveur DOIT envoyer une 406 (non acceptable) de réponse.

    • Ou, parce que ce n'est pas nécessaire et c'est très peu probable que l'utilisateur n'accepte pas tout des types de contenu (sinon, pourquoi serait-ils la peine d'envoyer la demande?) ... Je dirais le traitement d'un vide Accept: valeur (si le message de rejet n'est pas une option), les mêmes que Accept: */*.
    • Je suis en désaccord sur vide en-têtes difformes, d'autant que la spécification elle-même renvoie à vide en-têtes (voir mon Accept-Encoding exemple). Pour donner le contexte, je suis en développement web en python middleware et la réflexion sur les éventualités, et comment tester contre eux. Je suis allé en supposant */*, ce qui semble raisonnable pour moi aussi. Merci de prendre le temps!
    • Je pense aussi que 400 Bad Request serait plus approprié que 406 Not Acceptable, au moins si nous supposons que c'est une violation de la spécification. Cause dans cette affaire, nous avons été incapables de comprendre ce que le client accepte.
    • Vous savez, vous avez raison à propos de 2616-2.1 -- le #element formulaire n'indiquent vide de valeurs d'en-tête sont d'accord. Je vais mettre à jour ma réponse à en tenir compte, et d'éviter la désinformation. Aussi, je pense que ce fait soit une 406 de réponse ou de traiter comme Accept: */* valide. Mais probablement pas un 400 puisqu'il n'est pas techniquement un message d'erreur.
    • Si vous allez à la 406 route ou le */* route, je pense que se résume à votre préférence entre exactitude et la robustesse dans ce cas. Il semble que ce soit valide du point de vue de la spec est concerné.
    • Désolé pour le commentaire-spam. Vous savez ce qui est intéressant, c'est que de toutes les négociations de type accepte en-têtes, Accept est le seul spécifié avec #element. Tous les autres, à définir précisément 1#element. Je me demande pourquoi? Il ne fait pas beaucoup de sens pour moi que de l'autre l'acceptation des en-têtes de suivre le même format (où q-valeurs et les délimiteurs sont concernés). C'est intéressant, mais sur la surface, il semble comme un échec dans le spec-design afin d'avoir cette incohérence. Peut-être que je me trompe, mais je ne vois pas dans quel but il pourrait servir à permettre à 0 --> n Accept définitions tête.
    • Je suis totalement d'accord avec vous. Peut-être que c'est juste une faute de frappe qui a glissé à travers les commentaires. Et vous avez probablement raison sur 400 de façon inappropriée à nouveau, car il est # et pas 1#...

    InformationsquelleAutor rdlowrey
  2. 5

    Selon http://tools.ietf.org/html/rfc7231#section-5.3.2:

    Une demande sans Accepter d'en-tête de champ implique que l'agent de l'utilisateur accepte tout type de média en réponse.

    Vous devez traiter un inexistante Accept en-tête comme */*.

    • Vrai, mais vous êtes en citant une norme obsolète.
    • est la spécification actuelle celui-ci: tools.ietf.org/html/rfc2616#section-14.1 ?
    • Pas de. La RFC 2616 a été rendu obsolète par la Rfc 7230 etc.
    • merci pour la mise à jour 🙂
    • Le problème est-il ici la demande n'ont Accepter un champ d'en-tête, il n'a qu'une valeur vide.
    • Quentin a raison, mais je suis ici à la recherche d'exactement ce que cd1 répondu. Je commence à apprécier les réponses même si elles ne sont pas directement applicables.

    InformationsquelleAutor cd1