Requests: 418 Je suis une théière

BTW, je suis conscient qu'il s'agit d'un changement décisif ; déprécier et retarder la prochaine version majeure, c'est bien.

Ligne de code en question : https://github.com/requests/requests/blob/master/requests/status_codes.py#L55

Veuillez noter les versions alternatives pour 200 OK : https://github.com/requests/requests/blob/master/requests/status_codes.py#L13

Hein. La seule chose qui me préoccupe, c'est l'utilisation d'unicode et de barres obliques inverses ; les requêtes ne les émettent pas, n'est-ce pas ?

Non, c'est uniquement pour la recherche inversée - même chose avec je suis une théière.

OK c'est bon. Le problème est que la mise en œuvre est utilisée comme preuve pour empêcher l'utilisation réelle du code d'état, ce qui va _éventuellement_ être un problème.

Veuillez consulter https://github.com/nodejs/node/issues/14644 et https://github.com/golang/go/issues/21326 pour des discussions concernant des changements similaires.

Je suis d'accord pour le supprimer, à moins que nous ne voulions ajouter d'autres codes de statut comme 420 et amis.

HTTPbin.org le garde cependant :)

Serveurs individuels, je m'inquiète moins :)

Envoyez un RP !

Faites-le contre la branche 3.0.0, ce sera un changement décisif.

Attendez! Je suis le gars derrière http://save418.com (https://github.com/WhataShane/save418). Comme beaucoup d'autres , j'aime tomber sur des gags (presque entièrement) inoffensifs comme le 418. C'est le genre de chose qui vous fera sourire même lorsque vous êtes pressé de respecter une échéance de projet et que votre patron vous jappe. un bureau plus. Ce serait vraiment dommage de le voir partir.

Pour citer @romellem du fil Go, qui résume assez éloquemment l'argument pour 418 :

Juste pour être clair, votre argument est-il que lorsque/si le bloc 400 s'épuise, nous voudrons qu'un code supplémentaire soit disponible pour étendre un peu plus l'utilité du bloc 400 ?

Sauf si je le lis mal, le bloc 400 de codes d'état HTTP a plus de 50 codes disponibles. Avec "l'espace" disponible du bloc 400 à plus de 50 %, cela pourrait être une optimisation prématurée pour un problème qui ne se produira peut-être jamais (bloc 400 à court de codes disponibles, c'est-à-dire).

Je n'essaie pas de paraître dur, mais pour ma part, j'aime les petits œufs de Pâques amusants que l'on trouve tout au long d'une carrière en programmation. Pour moi, cela montre que tout ce qui fait qu'un ordinateur fonctionne réellement est toujours fabriqué par des humains, et garder de petites tranches de cet élément humain est bien (à mon avis). Votre argument est solide et logique, mais ce changement demandé réduit très légèrement le "fun-ness" de Go (et potentiellement de NodeJS) dans l'esprit de la robustesse de l'ingénierie. En fin de compte, je dois dire que je ne pense pas que ce compromis en vaille la peine.

(J'apprécie cependant la leçon d'histoire ! J'ai toujours pensé que 418 faisait partie de la spécification HTTP/1.x ; je ne connaissais pas la spécification "HTCPCP/1.0". )

Je suis d'accord que c'est un œuf de Pâques amusant.

Requests se prend au sérieux, mais pas trop au sérieux. :)

Cela pourrait être la ligne de "trop ​​​​sérieusement".

La réponse évidente n'est-elle pas ici d'en faire une partie de la spécification en commençant par une nouvelle RFC ?

@tSavo Clairement !

Bien que je reconnaisse que 418 ne fait pas partie de la spécification de code d'état HTTP dans la RFC 7231, il existe dans la nature. Même google l'a implémenté ici . Dans le cas peu probable où l'IETF déciderait de mettre en œuvre une utilisation réelle du 418, nous aurons beaucoup d'avertissements pour résoudre ce problème. Je suis en faveur de laisser cela tel quel, à moins qu'il n'y ait une raison plus impérieuse de le supprimer.

Donnez-moi vos clés.

Juste pour être clair, je suis d'accord avec le reste de l'équipe des requêtes : nous devrions conserver le mappage 418 ici. Mais la raison pour laquelle je suis d'accord est purement pragmatique, pas à cause de l'œuf de Pâques amusant (bien qu'il soit amusant): codes.py est utilisé pour construire une correspondance entre la phrase de raison et le code. Pour cette raison, il doit inclure toute phrase de raison qui est quelque peu susceptible d'apparaître pour un code donné. Pour le moment, je suis une théière. Si cela change, nous ajouterons toute autre phrase attribuée par l'IANA.

@mnot , n'hésitez pas à utiliser cette réponse comme un engagement qui dit que l'IETF/IANA devrait se sentir libre de réutiliser 418 et de ne pas le bloquer en notre nom. 😉 Je pense que les phrases de raison sont stupides de toute façon.

Une demande d'enregistrement 418 a été soumise à l'IANA , sous le numéro 979050.

D'accord; ce n'est pas un forum de discussion pour les mérites de 418. @mnot si vous voulez donner suite à ceci s'il vous plaît envoyez-moi un email. Pour tous les autres : nous apprécions votre contribution, mais je suis plutôt satisfait de la décision que nous avons prise.