Requests: 418 나는 찻주전자

BTW, 이것이 주요 변경 사항이라는 것을 알고 있습니다. 더 이상 사용하지 않고 다음 주요 릴리스로 연기하는 것은 괜찮습니다.

문제의 코드 라인: https://github.com/requests/requests/blob/master/requests/status_codes.py#L55

200 OK의 대체 버전을 참고하세요: https://github.com/requests/requests/blob/master/requests/status_codes.py#L13

뭐. 저를 걱정하게 만드는 유일한 것은 유니코드와 백슬래시를 사용하는 것입니다. 요청은 그것들을 방출하지 않습니다. 그렇지 않습니까?

아니요, 이것은 역방향 조회 전용입니다. I'm a teapot도 마찬가지입니다.

그래 괜찮네. 문제는 구현이 _결국_ 문제가 될 상태 코드의 실제 사용을 배제하는 증거로 사용된다는 것입니다.

유사한 변경 사항에 대한 논의는 https://github.com/nodejs/node/issues/14644 및 https://github.com/golang/go/issues/21326 을 참조 하십시오 .

420 및 친구와 같은 다른 상태 코드를 추가하지 않는 한 제거해도 됩니다.

HTTPbin.org는 그것을 유지하고 있습니다 :)

개별 서버, 나는 덜 걱정합니다 :)

홍보를 보내세요!

하지만 3.0.0 브랜치에 대해 만들면 이것은 주요 변경 사항이 될 것입니다.

기다리다! 저는 http://save418.com (https://github.com/WhataShane/save418) 뒤에 있는 사람입니다. 나는 다른 많은 사람들 과 마찬가지로 418과 같은 무해한 개그를 우연히 접하는 것을 즐깁니다. 프로젝트 마감일을 맞춰야 하고 상사가 당신에게 야단을 치는 경우에도 입가에 미소를 짓게 만드는 그런 종류의 것입니다. 사무실 하나가 끝났습니다. 가는 것을 보면 정말 부끄러울 것입니다.

418에 대한 주장을 아주 설득력 있게 요약한 Go 스레드의 @romellem 을 인용

분명히 하자면, 400 블록이 다 떨어지면 400 블록의 유용성을 조금 더 확장하기 위해 하나의 추가 코드를 사용할 수 있다는 주장이 있습니까?

내가 잘못 읽는 것이 아니라면 HTTP 상태 코드의 400개 블록에는 50개 이상의 코드가 있습니다. 400 블록의 사용 가능한 "공간"이 50% 이상인 경우 이것은 결코 발생하지 않을 수도 있는 문제에 대한 조기 최적화일 수 있습니다(400 블록에 사용 가능한 코드가 부족함).

거칠게 들리려고 하는 것은 아니지만 프로그래밍 경력을 통해 찾을 수 있는 재미있는 작은 부활절 달걀을 좋아합니다. 나에게 그것은 컴퓨터가 실제로 작동하게 만드는 모든 것이 여전히 인간에 의해 만들어지고 그 인간 요소의 작은 부분을 유지하는 것이 좋다는 것을 보여줍니다(제 생각에는). 귀하의 주장은 건전하고 논리적이지만 이 요청된 변경은 엔지니어링 견고성의 정신에서 Go(및 잠재적으로 NodeJS)의 "재미"를 약간 떨어뜨립니다. 결국에는 절충안이 가치가 없다고 생각합니다.

(그래도 역사 강의에 감사드립니다! 저는 항상 418이 HTTP/1.x 사양의 일부라고 생각했습니다. "HTCPCP/1.0" 사양에 대해서는 몰랐습니다. 🙂)

재미있는 부활절 달걀이라는 데 동의합니다.

요청 자체를 심각하게 받아들이지만 너무 심각하지는 않습니다. :)

이것은 "너무 심각하게"의 라인 일 수 있습니다.

여기에 새로운 RFC로 시작하여 사양의 일부로 만드는 것이 분명한 답이 아닙니까?

@tSavo 분명히!

418은 RFC 7231의 HTTP 상태 코드 사양의 일부가 아니지만 실제로 존재합니다. 구글 조차도 여기 에서 구현

열쇠를 주세요.

명확히 하자면, 나머지 요청 팀의 의견에 동의합니다. 여기에서 418 매핑을 유지해야 합니다. (재미는 있지만)하지만 동의 이유 때문이 아니라 재미 부활절 달걀의 순수 실용적입니다 : codes.py 코드에 이유 문구 대응 관계를 구축하는 데 사용됩니다. 이러한 이유로 주어진 코드에 대해 나타날 가능성이 있는 모든 이유 문구를 포함해야 합니다. 그 순간 I'm A Teapot. 이것이 변경되면 IANA가 할당하는 다른 문구를 추가합니다.

@mnot , IETF/IANA가 418을 자유롭게 재사용하고 우리를 대신하여 차단하지 않아야 한다는 약속으로 이 응답을 자유롭게 사용하십시오. 😉 어쨌든 이유 문구는 어리석은 것 같아요.

418 등록 요청이 번호 979050

확인; 이것은 418의 장점에 대한 토론 포럼이 아닙니다. @mnot 이에 대한 후속 조치를 원하시면 저에게 이메일을 보내주십시오. 다른 모든 사람들을 위해: 귀하의 의견에 감사드립니다. 하지만 저는 우리가 내린 결정에 대해 매우 기분이 좋습니다.