Style de saut de ligne d'en-tête HTTP


161

Quel style de saut de ligne est préférable pour une utilisation dans les en-têtes HTTP: \r\nou \n, et pourquoi?

Réponses:


224

\r\n, car il est défini comme le saut de ligne dans la spécification du protocole. La RFC2616 déclare au début de la section 2.2, «Règles de base» , sans ambiguïté:

CR = <US-ASCII CR, retour chariot (13)>
LF = <US-ASCII LF, linefeed (10)>
HTTP / 1.1 définit la séquence CR LF comme marqueur de fin de ligne pour tous les éléments du protocole à l'exception de l'entité -corps

La RFC2616 était techniquement obsolète par la RFC7230, mais elle n'apporte aucun changement radical et appelle à nouveau CRLF comme délimiteur dans la section 3 , et que la RFC fait référence à RFC5234, Annexe B.1 pour définir "CRLF" comme %x0D %x0A.

Cependant, reconnaissant que les gens enfreindront la norme à quelque fin que ce soit, il existe une «disposition de tolérance» à l' article 19.3 (notez qu'elle réitère la séquence correcte ):

Le terminateur de ligne pour les champs d'en-tête de message est la séquence CRLF. Cependant, nous recommandons que les applications, lors de l'analyse de ces en-têtes, reconnaissent un seul LF comme terminateur de ligne et ignorent le CR de tête.

Dans la nouvelle RFC7230, § 3.5

Bien que le terminateur de ligne pour les champs de ligne de début et d'en-tête soit la séquence CRLF, un destinataire PEUT reconnaître un seul LF comme terminateur de ligne et ignorer tout CR précédent.

Par conséquent, à moins que vous ne vouliez être mauvais ou enfreindre les règles de la RFC, utilisez \r\n.


@Fred: Non, il y a une telle chose comme étant trop évidente - une répétition inutile et une répétition inutile et une répétition inutile des mêmes informations obscurcissent le message. Surtout quand la même chose est citée juste au-dessus - de la spécification, rien de moins.
Piskvor a quitté le bâtiment le

2
Bonne réponse claire. C'est exactement ce pour quoi StackOverflow est le mieux: des réponses simples et claires à des questions simples et claires, sans l'encombrement inutile et inutile de blogs et d'articles.
Miles Rout

@MilesRout: Merci :)
Piskvor a quitté le bâtiment

2
@Pacerier: Ne mentionne rien de tel; comme il spécifie essentiellement "c'est la seule syntaxe valide pour HTTP", tout le reste est une syntaxe invalide. Bien sûr, vous pouvez violer la RFC tout ce que vous voulez, personne ne peut vous arrêter - mais techniquement, vous n'implémentez plus techniquement un client HTTP, juste quelque chose qui ressemble à quelque chose de similaire;)
Piskvor a quitté le bâtiment

2
La RFC7230 qui rend obsolète la RFC2616 contient le même texte dans la section 3.5
Grief

22

\ r \ n parce que RFC 2616 le dit (Section 2.2, «Règles de base»):

HTTP / 1.1 définit la séquence CR LF comme le marqueur de fin de ligne pour tous
les éléments de protocole à l'exception du corps d'entité (voir l'appendice 19.3 pour
les applications tolérantes). Le marqueur de fin de ligne dans un corps d'entité est défini par son type de média associé, comme décrit dans la section 3.7.

   CRLF           = CR LF

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.