Requests: 418 Soy una tetera

Por cierto, soy consciente de que este es un cambio radical; desaprobar y retrasar hasta la próxima versión principal está bien.

Línea de código en cuestión: https://github.com/requests/requests/blob/master/requests/status_codes.py#L55

Tenga en cuenta las versiones alternativas para 200 OK: https://github.com/requests/requests/blob/master/requests/status_codes.py#L13

Eh. Lo único que me preocupa es el uso de Unicode y barras invertidas; las solicitudes no las emite, ¿verdad?

No, esto es solo para búsqueda inversa, lo mismo que soy una tetera.

Ok, eso es bueno. El problema es que la implementación se está utilizando como evidencia para excluir el uso real del código de estado, lo que _ eventualmente_ será un problema.

Consulte https://github.com/nodejs/node/issues/14644 y https://github.com/golang/go/issues/21326 para obtener información sobre cambios similares.

Estoy de acuerdo con eliminarlo, a menos que queramos agregar otros códigos de estado como 420 y amigos.

Sin embargo, HTTPbin.org lo mantiene :)

Servidores individuales, me preocupa menos :)

Envíe un PR!

Sin embargo, hágalo contra la rama 3.0.0, este será un cambio importante.

¡Esperar! Soy el tipo detrás de http://save418.com (https://github.com/WhataShane/save418). Yo, como muchos otros , disfruto tropezar con (casi por completo) bromas inocuas como 418. Es el tipo de cosas que te harán sonreír incluso cuando estés presionado para cumplir con la fecha límite de un proyecto y tu jefe te esté ladrando una oficina más. Sería una verdadera lástima verlo irse.

Para citar a @romellem del hilo de Go, quien resume de manera bastante elocuente el argumento de 418:

Para ser claros, ¿su argumento es que cuando / si el bloque 400 se agota, queremos que haya un código adicional disponible para extender la utilidad del bloque 400 un poco más?

A menos que lo esté leyendo incorrectamente, el bloque 400 de códigos de estado HTTP tiene más de 50 códigos disponibles. Con el "espacio" disponible del bloque 400 en más del 50%, esto podría ser una optimización prematura para un problema que tal vez nunca ocurra (es decir, el bloque 400 se queda sin códigos disponibles).

No intento sonar duro, pero a mí me gustan los divertidos huevos de Pascua que encuentras a lo largo de una carrera en programación. Para mí, muestra que todo lo que hace que una computadora funcione de verdad lo hacen los humanos, y mantener pequeñas porciones de ese elemento humano es bueno (en mi opinión). Su argumento es sólido y lógico, pero este cambio solicitado reduce ligeramente la "diversión" de Go (y potencialmente de NodeJS) en el espíritu de la robustez de la ingeniería. Al final del día, tengo que decir que no creo que la compensación valga la pena.

(¡Aprecio la lección de historia! Siempre pensé que 418 era parte de la especificación HTTP / 1.x; no conocía la especificación "HTCPCP / 1.0". 🙂)

Estoy de acuerdo en que es un huevo de pascua divertido.

Requests se toma en serio, pero no demasiado. :)

Esta podría ser la línea de "demasiado en serio".

¿No es la respuesta obvia aquí convertirlo en parte de la especificación comenzando con un nuevo RFC?

@tSavo ¡Claramente!

Si bien reconozco que 418 no es parte de la especificación del código de estado HTTP en RFC 7231, existe en la naturaleza. Incluso google lo ha implementado aquí . En el improbable caso de que el IETF decida implementar un uso real para 418, tendremos muchas advertencias para abordar esto. Estoy a favor de dejar esto como está a menos que haya una razón más convincente para eliminarlo.

Dame tus llaves.

Para que quede claro, estoy de acuerdo con el resto del equipo de Solicitudes: deberíamos mantener el mapeo 418 aquí. Pero la razón por la que estoy de acuerdo es puramente pragmática, no por el divertido huevo de Pascua (aunque es divertido): codes.py se usa para construir un mapeo de la frase de la razón al código. Por esta razón, debe incluir cualquier frase de razón que sea algo probable que aparezca para un código dado. Por el momento soy una tetera. Si esto cambia, agregaremos cualquier otra frase que asigne la IANA.

@mnot , siéntase libre de usar esta respuesta como un compromiso que dice que el IETF / IANA debe sentirse libre de reutilizar 418 y no bloquearlo en nuestro nombre. 😉 Creo que las frases de razón son estúpidas de todos modos.

Se ha enviado una solicitud para registrar 418 a IANA , con el número 979050.

OK; este no es un foro de discusión sobre los méritos de 418. @mnot, si desea hacer un seguimiento de esto, por favor envíeme un correo electrónico. Para todos los demás: agradecemos sus aportes, pero me siento bastante bien con la decisión que hemos tomado.