Node: 418 Soy una tetera

@ nodejs / http

La "implementación" se define libremente en este caso dado que Node.js no hace nada con él más que asignar el mensaje de estado predeterminado si se usa. Podríamos desaprobar el mensaje de estado de la tetera y reasignarlo fácilmente más tarde como semver major. En la implementación de http2, puedo asegurarme de que aún no se le haya asignado una constante.

Parece que 418 técnicamente no está registrado en la IANA .

FWIW, parece que Go también es compatible con 418. Sin embargo, no estoy seguro de que haya soporte en ningún otro lugar.

Una mudanza sería semver-major. No estoy seguro de que quisiéramos agregar la sobrecarga de verificar explícitamente que 418 haga una desaprobación del tiempo de ejecución.

Sí, estoy pensando que los documentos solo están obsoletos en 9.xy EOL en 10.x

WFM, gracias. Yo perseguiré a Go.

No estoy seguro de que esto realmente requiera una función, per se. Soy en gran parte indiferente, si podemos hacer el cambio y la gente lo quiere, ¿seguro?

¿Hay alguna razón para eliminar esto ahora ? Es una trivia divertida que agrega sabor sin dañar a nadie; sería trivial eliminarlo si se agrega un error real 418 a HTTP (o si se agregan suficientes errores que comienzan a quedarse sin números).

¿Hay alguna razón para eliminar esto ahora?

Si. Dado que cambiarlo requeriría un estilo de desaprobación semver-mayor completo, comenzar el proceso de desaprobación de esto ahora nos permite adoptar cualquier código de estado 418 real futuro mucho más rápido más adelante. Ya estamos comprometidos a mantener el I'm a teapot estado 8.x que será apoyada por los próximos 32 meses. Si esperamos más, nos comprometeremos a que también se incluya en 10.0 LTS, lo que lo eliminaría varios años más después.

Tenga en cuenta que el cambio sugerido aquí no impedirá que nadie use 418 con la semántica de HTCPCP si lo desea, solo eliminará el soporte predeterminado de Node para él.

Sorprendido que aún no esté publicado aquí, pero ... http://save418.com/

Solo soy un espectador, pero esa es una oposición bastante fuerte. :)

@addaleax Una broma no es muy divertida si te la cuentas a ti mismo; la eliminación del nodo 418 no me impedirá su aplicación a mí mismo, pero va a quitar un divertido y peculiar huevo de Pascua de tropezar con - que es lo que todo el mundo se lamenta.

comenzar el proceso de desaprobar esto ahora nos permite adoptar cualquier código de estado 418 real futuro mucho más rápido más adelante

¿Y existen actualmente propuestas que significarían que 418 tendrá un propósito legítimo?

Me doy cuenta de que, en un futuro lejano, es posible que necesitemos usar este código, pero eliminar un huevo de pascua de 20 años ampliamente conocido solo por el bien de la limpieza me parece un poco innecesario.

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 quizás 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 realmente sigue siendo hecho por 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". 🙂)

¿Hay propuestas actualmente que significarían que 418 tendrán un propósito legítimo?

Si. Se está discutiendo una propuesta para un nuevo código de estado 4xx. Dado que 418 no está registrado oficialmente, (en teoría) debería usarse para el nuevo código, pero no necesariamente tiene que ser ... Simplemente no es algo que dependa de nosotros en absoluto.

El hilo está aquí si alguien está interesado.

Como alguien que participó en la implementación de rfc2549 para el IDF (¡NO!), Estoy +1 en excluir 418 de HTTP, por lo tanto, en mi humilde opinión, debería permanecer en node . (hasta que IETF o IANA decida lo contrario)

@refack : IANA no lo registra y el IETF no lo reconoce (el RFC que lo define es un RFC de broma). Entonces, ¿estás diciendo que apoyas la eliminación o no? confundido

Como se mencionó, todavía quedan más de 50 códigos HTTP en el rango de 400, dudo que esto sea un problema en el futuro cercano. Por favor, no mates cosas divertidas por una razón tan pequeña, recuerda que nosotros mismos no somos computadoras.

@ max213 Como se explicó, esto será un problema en el futuro, si HTTP dura tanto como esperamos. Arreglarlo entonces será MUCHO más difícil que arreglarlo ahora (vea la resistencia que ya estamos encontrando y magnifíquela considerablemente).

Los códigos de estado HTTP están definidos por el registro de IANA. Si tenemos implementaciones que reclaman códigos de estado fuera de él, es malo; El nodo NO está implementando HTTP aquí. Respete el protocolo.

@refack : IANA no lo registra y el IETF no lo reconoce (el RFC que lo define es un RFC de broma). Entonces, ¿estás diciendo que apoyas la eliminación o no? confundido

Estoy diciendo que hasta que esté registrado para cualquier otra cosa, en mi humilde opinión, debería quedarse.
Si usted o la IANA deciden aceptar el status quo, sería lindo. Supongo que hay otros códigos que se usan con menos frecuencia.

PD: Vivo al lado de un puente cuya longitud es "364.4 SMOOTS + 1 EAR" y conduce a las oficinas del W3C.

PPS Siendo la única persona que también es una unidad de longitud, Smooth creció hasta ser el presidente de ANSI y más tarde el presidente de ISO.

Estoy diciendo que hasta que se registre para cualquier otra cosa, en mi humilde opinión, debería permanecer.

El problema es que su inclusión en implementaciones como Node se usa para argumentar en contra de que el código se use para otros propósitos (reales).

Incluso si lo es, hay más de 50 lugares vacantes que ya están abiertos. ¿Por qué el 418 tiene que ser reemplazado por un código de error "real" cuando no estamos cerca de llenar todos los otros 4XX?

Estoy diciendo que hasta que se registre para cualquier otra cosa, en mi humilde opinión, debería permanecer.

El problema es que su inclusión en implementaciones como Node se usa para argumentar en contra de que el código se use para otros propósitos (reales).

Entiendo eso ... Pero, bueno, Internet es una gran bola de barro (Excepto por el increíble trabajo realizado por el IETF) ver https://bz.apache.org/bugzilla/show_bug.cgi?id=61383

_{Solo me represento a mí mismo y no bloquearé si hay un impulso para desaprobar 418}

@mnot No entiendo por qué esto es un problema. Si alguna vez hay una afluencia repentina de nuevos códigos de estado HTTP, honestamente, puede poner otro 0 al final y podemos tener 1000 códigos de estado. También está asumiendo que HTTP 3 seguirá usando códigos de estado, podría usar códigos hash o tuplas o cualquier cosa, honestamente.

Este es un tema que está tan lejos en el futuro sobre el que no vale la pena actuar porque no sabemos cómo será el panorama.

Además, 418 tiene usos en aplicaciones de producción reales; consulte https://developer.amazon.com/dash-replenishment-service para ver un ejemplo.

El problema es que su inclusión en implementaciones como Node se usa para argumentar en contra de que el código se use para otros propósitos (reales).

@mnot ¿ Su adopción por parte de la comunidad HTTP en general se utiliza para argumentar en contra de su uso para otros fines? Eso me parece bastante justo; me imagino que así es aproximadamente como cualquier otro código sería aceptado en el protocolo si no se hubiera originado allí (por ejemplo, 444 de nginx). Probablemente sería preferible argumentar a favor de su inclusión en el protocolo, pero dada su naturaleza, creo que es razonable simplemente evitar usar su código antes de que sea necesario.

Independientemente, hay poco daño en implementar 418 en Node - notablemente, no va en contra del protocolo HTTP (donde 418 es "No asignado", no "No permitido").

@ maxh213 :

honestamente, puede poner otro 0 al final y podemos tener 1000 códigos de estado

No, no puedes. Este sería un cambio importante y rompería todas las implementaciones que (muy razonablemente) simplemente asumen que pueden hacer, por ejemplo, status <= 500 && status > 400 para determinar si el servidor tuvo un error, de cualquier tipo. Esto es incluso compatible con versiones posteriores incluso si se agregan nuevos estados que el cliente no conoce.

También está asumiendo que HTTP 3 seguirá usando códigos de estado

Tal protocolo sería muy diferente de HTTP y posiblemente merecería un nombre diferente. Además, está asumiendo que incluso habrá un HTTP / 3. Idealmente, seguiríamos haciendo cosas compatibles con versiones anteriores y ni siquiera necesitaríamos HTTP / 3.

Cruzando los arroyos; también planteado en https://github.com/golang/go/issues/21326 y https://github.com/aspnet/HttpAbstractions/issues/915

El problema es que su inclusión en implementaciones como Node se usa para argumentar en contra de que el código se use para otros propósitos (reales).

Bueno. Pueden usar 418 después de llenar 400-417 y 419-499. 418 debería vivir como "Soy una tetera" el mayor tiempo posible.

¿Le está causando algún daño a Node? Broma o no, ¿es legítimamente parte de la especificación HTTP?

Por lo general, soy un guerrero rabioso a favor del desprecio, incluso si rompe el código de alguien. Porque nunca puedes evitar romper nada de todos modos, incluso si estás arreglando un error no controvertido. Sin embargo, encuentro esta solicitud mezquina y contra el espíritu del software de código abierto.

El código 418 es un huevo de pascua muy conocido en la historia de los protocolos de Internet y los propios RFC. Es parte de nuestra historia. Soportar una única constante en un lugar no implica ninguna carga de mantenimiento, y la afirmación del solicitante de que tener esta constante sería problemático dentro de 50 años, cuando todavía usaremos HTTP y nos quedaremos sin códigos de estado, no se sostiene.

Dado que un argumento importante para desaprobar el código de estado 418 es su falta de registro IANA, ¿por qué no registrarlo realmente?

El Registro de códigos de estado HTTP de IANA muestra 418 como no asignado y, presumiblemente, es poco probable que asigne este valor a cualquier otro código de estado dada la adopción conflictiva de facto en muchas implementaciones (posiblemente heredadas / rotas).

Bien, seguí adelante y envié la solicitud, pase lo que pase:

A quien le interese:

Este es un mensaje generado automáticamente para notificarle que tenemos
recibió su solicitud, y se ha registrado en nuestra emisión de boletos
sistema con un número de referencia de 979050.

No es necesario responder a este mensaje en este momento. El personal de la IANA
revise su mensaje en breve.

Si este mensaje es en respuesta a un ticket enviado previamente, es
posible que el ticket anterior haya sido marcado como cerrado. Como nosotros
revisar este ticket, también revisaremos la correspondencia anterior y
tomar la acción apropiada.

Para agilizar el procesamiento y garantizar que nuestro personal pueda ver el historial completo
de esta solicitud, asegúrese de incluir el siguiente texto exacto en
el asunto de toda la correspondencia futura sobre este tema:

     [IANA #979050]

También puede simplemente responder a este mensaje, ya que esta etiqueta ya está en
la línea de asunto.

Gracias,

Servicios de IANA
[email protected]
PTI

Nombre de contacto:
Sebastiaan Deckers

Email de contacto:
[email protected]

Tipo de asignación:
Valor: 418
Descripción: soy una tetera

Registro:
Códigos de estado HTTP

Descripción:
Los esfuerzos para eliminar el código de estado 418 de las implementaciones HTTP populares (Node.js, Go, Request) se encontraron con la resistencia vocal de los usuarios (por ejemplo, http://save418.com, https://github.com/nodejs/node/issues/ 14644, https://github.com/requests/requests/issues/4238#issuecomment-321705847).

Aproximadamente la mitad de los códigos 4xx todavía están sin asignar, por lo que actualmente hay poca necesidad de "liberar" 418 por razones de escasez.

La adopción de facto de 418 (quizás más ampliamente que muchos códigos de estado asignados, debido a su naturaleza de broma) significa que no es deseable asignar el valor a especificaciones futuras. Hacerlo podría generar conflictos con muchas implementaciones heredadas.

La eliminación de 418 de las bases de código existentes requiere que algunas implementaciones pasen por un ciclo de lanzamiento importante. Este proceso puede durar varios años. (por ejemplo, https://github.com/nodejs/node/issues/14644#issuecomment-321570504)

El registro del código de estado 418 traerá el cumplimiento de los estándares a las implementaciones HTTP existentes con un esfuerzo mínimo. Las implementaciones que actualmente no implementan 418 agregarían soporte como con cualquier código de estado recién asignado. Las implementaciones que ya lo soportan no se ven afectadas.

El cambio debe ser en su mayoría compatible con versiones anteriores, ya que el código de estado nunca se ha asignado de otra manera (AFAIK).

Wile RFC2324 define un protocolo de broma inventado, April Fool's (HTCPCP / 1.0), el valor / descripción definido en 2.3.2 está implícito como un código y mensaje de estado compatible con HTTP / 1.1. El documento hace múltiples referencias a estar "basado en HTTP".

Información adicional:
https://www.ietf.org/rfc/rfc2324.txt
https://tools.ietf.org/html/rfc7231

¡La comunidad hapi apoya 418 Teapot! Boom es un módulo central en hapi
https://github.com/hapijs/boom/search?utf8= ✓ & q = tetera

Para ser aceptado, me gustaría ver un video de Youtube de @mnot cantando "Soy una pequeña tetera" con movimientos de manos.

@ max213 Como se explicó, esto será un problema en el futuro, si HTTP dura tanto como esperamos. Arreglarlo entonces será MUCHO más difícil que arreglarlo ahora (vea la resistencia que ya estamos encontrando y magnifíquela considerablemente).

Cuento 69 códigos de estado 4XX disponibles en IANA . Si necesitamos los 69 con tanta urgencia, ¿no es inevitable que también necesitemos 70?

La realidad es que si llegamos a este punto, alguien modificará el protocolo. Tal vez permita períodos 400.12 o elija el dígito más significativo para que 4001 se agrupe con el nivel 400, o elija que los 600 extiendan los 400, o permita dígitos hexadecimales para que 499 + 1 = 49A Muchas posibilidades, no hay valor en la pedantería aquí.

@JoshCheek : Estoy de acuerdo con ese punto. Probablemente sucederá de manera similar al protocolo WS13+ (websockets), y se colocará después de que se haya producido un UPGRADE de la conexión.

Quiero decir, incluso HTTP / 2.0 (o SPDY) se estaban colocando después de una actualización del protocolo; por lo que es muy poco probable que HTTP / 3.0 use todo sin una actualización _y_ con un encabezado HTTP / 1.1 _y_ con el mismo rango de códigos de estado, ya que las versiones posteriores del protocolo ya usan el mecanismo de actualización por razones de compatibilidad heredada.

Me gustaría sugerir una contrapropuesta: la incorporación de HTCPCP en el estándar HTTP .

Solo un espectador, pero sintió la necesidad de decir: el bloque 400 es 69% gratis. HTTP comenzó a desarrollarse en 1989 y, 28 años después, solo tenemos 31 códigos de 400 bloques. Suponiendo que esta tasa de quema continúe (que no será así), será alrededor del año 2100 cuando "necesitaríamos" liberar un código de 400 bloques.

¿Es normal que nodejs planifique con tanta anticipación al tomar decisiones técnicas?

¿De qué manera admite Nodo el estado 418 de todos modos? ¿No es solo el cuerpo predeterminado si devuelve el estado 418?

Si había un mensaje predeterminado para otros códigos, como:

if (is_unassigned(status)) {
    message = "Hello, this is the default message for HTTP " + status;
}

¿Se quejaría la gente de que Node admite otros códigos de estado no estándar como 419?

Sería una situación diferente si hubiera un módulo de tetera completo, o algo dependiera de este comportamiento. Pero tal como está ahora, no hay ningún impedimento técnico para que alguien más siga adelante y simplemente asigne un significado a 418. Sería desafortunado, perderíamos una broma. Pero probablemente sería un cambio de una línea para reemplazar "No soy una tetera" con el nuevo significado.

(Dicho sea de paso, si hay algo que podría ser perjudicial para registrar 418 oficialmente con el significado broma, ya que hace uso futuro se oponen! Llevar la especificación y la implementación en línea sólo por el hecho de que, al cambiar la especificación, es tonta. _Editar_: Quiero decir en el caso de una broma tonta, no en general. Si alguien usa 419 como "Soy un ornitorrinco", no lo estandarice. Si 420 se usa ampliamente con un significado sensato, seguro , ¡adelante!)

No creo que el código 418 esté haciendo ningún daño. Déjalo.

Arrancarlo es una pérdida inútil del tiempo de todos. Puede que no sea parte de ningún estándar oficial , pero es una parte aceptada del historial de Internet. Y a menos que vaya a revisar todos los lenguajes, todos los marcos y todas las bibliotecas HTTP que se hayan escrito y cree un PR para ellos, suponiendo que tenga esa opción, eliminarlo de un subconjunto de ellos causará más confusión y problemas.

@jdmansour No estoy de acuerdo con que sea perjudicial registrar 418 oficialmente por estas razones. Deberíamos haber aprendido del desarrollo de la especificación XHTML en comparación con HTML5 que la especificación debe basarse en la realidad, y no al revés.

De acuerdo con @ stevehill1981 : nosotros, como comunidad de Internet, deberíamos crear estándares de manera descriptivista. No deberíamos intentar ser L'Académie française para Internet. Nuestro objetivo final como creadores, como las personas que impulsan lo que está detrás de lo que mucha gente ve, debería ser mejorar la experiencia de los millones de usuarios finales que acceden a los servicios que impulsamos y creamos colectivamente.

¿Cómo beneficia este tipo de decisión a los usuarios finales? Respuesta: no es así.

Volvamos a trabajar en cosas que son realmente importantes para el mundo.

¡Deje 418 en paz!

Qué tontería de la que quejarse, es un pequeño código lindo que no ha hecho nada malo ...

Como otros ya han observado: incluso si aparece un nuevo tipo de error 4xx , seguramente el próximo candidato para su número no será 418, debido a esta ambigüedad. Incluso si es técnicamente "gratuito" de usar, seguramente se evitaría porque la mayoría de la gente habrá oído hablar de él debido a esta broma sobre la tetera.

De lo contrario, es un toque humano en un trabajo bastante complejo y orientado al futuro que todos usan todos los días. No es un error tener estas cosas en nuestro código. ¿Recuerda cuando agregamos rebeccapurple como valor de color ? Estas cosas nos recuerdan que la gente real creó estos estándares y herramientas y la gente real los está usando y trabajando con ellos. Claro, 418 I'm A Teapot es una broma, un poco divertida, pero ¿por qué es esta una razón para eliminarla?

Además: Internet de las cosas es tan omnipresente en estos días que, tarde o temprano, es posible que una tetera conectada a Internet necesite usar este código de respuesta. ¡¿Queremos ser nosotros los que les nieguemos esa oportunidad ?!

Mientras estamos en esto, ¿por qué no sacar la escopeta y volar todas las palomas que son parte de una implementación RFC1149 del cielo (o cooperativa)? ¿O quemar todos los bongos prematuramente?

¡Me gusta 418, lo usé en Producción y ni siquiera bebo té! :)

(editar: agregar) # Save418

Oye, no dejes comentarios # save418 - crean mucho ruido. Si desea indicar que está a favor o en contra de la eliminación del código de estado sin participar en la discusión técnica, utilice las reacciones.

Me gustaría señalar a cualquier persona que participe que estamos buscando más colaboradores en el nodo y hay un montón de problemas con etiqueta "-buena primera contribución" de nada para recoger y le ayuda.

@m no
Si cree que nos vamos a quedar sin códigos de error HTTP en un futuro próximo, debe intentar encontrar una manera de corregir el diseño. Un solo código de error no va a resolver eso.

@haydenk HTTP 418 no forma parte de la especificación HTTP. Es parte de OTOH de una broma tonta de abril y ahora, irónicamente, la mitad de Internet piensa que es parte de la especificación HTTP. Ahora tenemos a @mnot , que preside el grupo de trabajo IETF HTTP, diciendo muy específicamente por qué esto no es parte de la especificación HTTP, y las reacciones en este hilo (y la comunidad de Internet en general) son francamente alarmantes.

El problema con los principales proveedores de marcos que implementan esto es la compatibilidad con versiones anteriores, el apartado 418 no es parte del estándar HTTP. IANA dice que no está asignado, lo que puede deberse a que entra en conflicto con los sistemas heredados existentes o puede estar reservado en el futuro para otros fines. Algunos pueden argumentar que deberíamos usar y solicitar 418 para que se convierta en parte del estándar en una especificación futura. Hablando históricamente, alguien malinterpretó un documento RFC (eso fue un tonto) , pensó que era parte del estándar HTTP, de alguna manera pasó por un proceso de revisión y ahora el nodo (entre muchos otros) piensa que es parte de la especificación. Es por eso que, en mi opinión, esto es un error, y realmente no espero que alguien cometa un error (o como parte de una broma) haga que esto sea parte de la especificación HTTP. Para poner las cosas en perspectiva, ¿por qué no comenzamos a argumentar que algún verbo HTTP inútil debería convertirse en parte de la especificación HTTP solo porque los principales proveedores de marcos web pensaron que sería una broma divertida de Aprils?

El problema con los principales proveedores de marcos que implementan esto es la compatibilidad con versiones anteriores.

Compatibilidad con versiones anteriores de ... ¿qué?

TBH No creo que el registro de la IANA se lleve a @sebdeckers exprese su descontento con este cambio.

@ tyteen4a03 Si hay una nueva especificación que dice que 418 se usa para algo más que "Soy una tetera", NodeJS tendría que desaprobar esto y eliminarlo gradualmente. No pueden simplemente eliminar esto, ya que introduce cambios en la API.

Compatibilidad con versiones anteriores de ... ¿qué?

Compatible con versiones anteriores de nuestro sentido del humor, supongo.

Estoy de acuerdo en que hay pocas razones técnicas, si es que hay alguna, a favor de necesitar la tetera 418. A pesar de eso, tampoco hay razones válidas para presionar tanto para su eliminación. No compro la afirmación de Mark sobre el espacio limitado del código de error HTTP y ya he dicho por qué esa pretensión no es sensata.
Un mejor argumento para la eliminación de 418 es bienvenido.

Si bien no me importa si 418 sigue siendo compatible con Node o no (o cualquier otra herramienta / tecnología), nunca estaría en contra de que IANA lo registre para un nuevo propósito.

Ha sido útil como código de estado que se puede usar en pruebas / simulacros para dejar en claro que el error es falso y no proviene de un sistema activo en el otro extremo.

Tetera o no, tener un código HTTP del que puede estar seguro de que un sistema de terceros con el que se está integrando no lo está enviando desde una API legítima es útil.

Lo que quiero decir es que esperar un uso legítimo de 418 no es un buen argumento en esta discusión.

edit: @sebdeckers también podría usar este argumento en su aplicación IANA.

¿Es este el lugar adecuado para discutir? Si desea cambiar el estándar, cree un RFC.
En mi opinión, Node debería implementar el estándar tal como está. De lo contrario, no necesitaríamos estándares.

Este es un cambio de bajo valor que no va a resolver el problema de quedarse sin códigos de error HTTP en el futuro cercano. Simplemente lo retrasará en 1, no vale la pena el esfuerzo en mi opinión.

Esto parece un cambio que no proporciona mucho valor, e incluso podría considerarse perjudicial en el futuro: dado el aumento de los dispositivos de IoT, es cada vez más probable una implementación en el mundo real de HTTP 418.

Todos, gracias por los comentarios divertidos y divertidos. Nos complace muchísimo que la característica más querida de Node.js sea una tetera. Creo que es seguro para nosotros dejar esto como está por ahora.

Estoy cerrando el problema y solo para evitar que este problema crezca indefinidamente durante todo el tiempo, lo bloquearé. Duerma cómodamente esta noche sabiendo que, al menos en el futuro previsible, sus aplicaciones web Node.js pueden proclamar con orgullo que ellas también son Teteras.