사용 가능한 Proxy-Authenticate 챌린지가 없는 HTTP 407

클라이언트는 상태 번호만으로 인증 메커니즘을 선택할 수 없습니다. 프록시의 응답은 무엇을 받아들이는지 설명해야 합니다.

HTTP는 407을 생성하는 프록시가 Proxy-Authenticate 챌린지를 보내도록 요구합니다. Basic 서비스의 간단한 예는 다음과 같습니다.

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Office proxy"

숫자 상태, 헤더 이름, 스킴별 구문이 모두 중요합니다. 본문에 authentication이라는 단어가 있는 브랜드 오류 페이지는 헤더를 대체하지 못합니다. 사용자 지정 구현도 헤더 종결자와 본문 프레이밍을 포함한 완전한 HTTP 407 응답을 보내야 합니다.

이 클라이언트에 도달한 응답을 확인하세요

비밀 값을 제거한 뒤 상태와 챌린지 필드를 기록하세요. 중간 장치가 응답을 변형했을 수도 있고, 사용자 지정 프록시가 잘못된 챌린지를 구성했을 수도 있습니다. 그 증거를 프록시 자체의 트랜잭션 로그와 비교하세요.

서비스가 대신 405나 다른 오류를 보낸다면, 사용자 지정 클라이언트 안에서 그런 응답을 모두 407로 다시 표시하지 마세요. 실제 메서드 정책 실패를 숨기면서도 신뢰할 수 있는 스킴 협상은 여전히 얻지 못합니다. 서비스 동작을 고치거나 문서화된 지원 인증 경로를 사용하세요.

여러 챌린지에는 실제 HTTP 파서도 필요합니다. 쉼표는 매개변수나 챌린지를 구분할 수 있습니다. 전체 헤더를 쉼표에서 무작정 나누면 따옴표로 묶인 realm이 손상될 수 있습니다. 연속된 문자열 치환 대신 클라이언트가 지원하는 인증 구현을 사용하세요.

챌린지가 사용 가능해진 뒤에야 자격 증명 공급자가 왜 계정을 반환하지 않았는지 조사하는 것이 의미가 있습니다.