Requests: 418 eu sou um bule

BTW, estou ciente de que esta é uma alteração significativa; suspender o uso e adiar para a próxima versão principal está certo.

Linha de código em questão: https://github.com/requests/requests/blob/master/requests/status_codes.py#L55

Observe as versões alternativas para 200 OK: https://github.com/requests/requests/blob/master/requests/status_codes.py#L13

Huh. A única coisa que me preocupa é o uso de Unicode e barras invertidas; pedidos não emite aqueles, não é?

Não, isso é apenas para pesquisa reversa - o mesmo com I'm a bule.

OK, assim está bom. O problema é que a implementação está sendo usada como evidência para impedir o uso real do código de status, o que vai _eventualmente_ ser um problema.

Consulte https://github.com/nodejs/node/issues/14644 e https://github.com/golang/go/issues/21326 para discussões sobre mudanças semelhantes.

Posso removê-lo, a menos que desejemos adicionar outros códigos de status como 420 e amigos.

HTTPbin.org o está mantendo :)

Servidores individuais, estou menos preocupado :)

Envie um PR!

Faça isso contra o branch 3.0.0, porém, esta será uma mudança significativa.

Aguentar! Sou o responsável por http://save418.com (https://github.com/WhataShane/save418). Eu, como muitos outros , gosto de tropeçar em piadas (quase inteiramente) inócuas como 418. É o tipo de coisa que vai colocar um sorriso no seu rosto, mesmo quando você está pressionado para cumprir o prazo de um projeto e seu chefe está latindo com você mais um escritório. Seria uma pena ver isso ir embora.

Para citar @romellem do tópico Go, que resume de maneira bastante eloquente o argumento de 418:

Só para ficar claro, seu argumento é que quando / se o bloco 400 acabar, vamos querer aquele código extra disponível para estender a utilidade do bloco 400 um pouco mais?

A menos que eu esteja lendo incorretamente, o bloco 400 de códigos de status HTTP tem mais de 50 códigos disponíveis. Com o "espaço" disponível do bloco 400 em mais de 50%, essa pode ser uma otimização prematura para um problema que pode nunca ocorrer (isto é, bloco 400 ficando sem códigos disponíveis).

Não estou tentando soar áspero, mas eu gosto de pequenos ovos de páscoa divertidos que você encontra ao longo de uma carreira de programação. Para mim, isso mostra que tudo o que acontece para fazer um computador realmente funcionar ainda é feito por humanos, e manter pequenas fatias desse elemento humano é bom (na minha opinião). Seu argumento é sólido e lógico, mas essa mudança solicitada reduz levemente a "diversão" do Go (e potencialmente do NodeJS) no espírito da robustez da engenharia. No final do dia, devo dizer que não acho que vale a pena compensar.

(No entanto, agradeço a lição de história! Sempre pensei que 418 fosse uma parte da especificação HTTP / 1.x; não sabia sobre a especificação "HTCPCP / 1.0". 🙂)

Eu concordo que é um ovo de páscoa divertido.

Requests se leva a sério, mas não muito a sério. :)

Esta pode ser a linha de "muito a sério".

A resposta óbvia aqui não é torná-la parte das especificações começando com um novo RFC?

@tSavo Clearly!

Embora eu reconheça que 418 não faz parte da especificação do código de status HTTP no RFC 7231, ele existe à solta. Até o Google implementou aqui . No caso improvável de o IETF decidir implementar um uso real para 418, teremos muitos avisos para resolver isso. Sou a favor de deixar como está, a menos que haja um motivo mais convincente para que seja necessário removê-lo.

Dê-me suas chaves.

Só para ficar claro, concordo com o restante da equipe de solicitações: devemos manter o mapeamento 418 aqui. Mas a razão pela qual concordo é puramente pragmática, não por causa do ovo de Páscoa divertido (embora seja divertido): codes.py é usado para construir um mapeamento da frase de razão para o código. Por esse motivo, ele deve incluir qualquer frase de razão que provavelmente aparecerá para um determinado código. Por enquanto, sou um bule. Se isso mudar, adicionaremos qualquer outra frase atribuída pela IANA.

@mnot , sinta-se à vontade para usar esta resposta como um compromisso que afirma que a IETF / IANA deve se sentir à vontade para reutilizar o 418, e não bloqueá-lo em nosso nome. 😉 Eu acho que as frases de razão são estúpidas de qualquer maneira.

Uma solicitação de registro 418 foi enviada à IANA , sob o número 979050.

OK; este não é um fórum de discussão para os méritos de 418. @mnão se você quiser acompanhar isso, mande-me um e-mail. Para todos os outros: agradecemos sua opinião, mas me sinto muito bem com a decisão que tomamos.