HTTP/1.1
HTTP/1.1을 정의한 최신 명세인 RFC 2616에 따르면, 흔히 알고 있는 것과는 달리 의외로 403 Forbidden은 권한(authorization)에 대한 에러가 아니다. 그냥 요청은 이해하지만 수행을 거절(refuse)하겠다는 의미이다.
그리고 또 의외로 400 Bad Request는 그냥 “요청이 잘못되었다”라는 의미가 아니라 “요청의 syntax가 잘못되어서 이해를 못하겠다”라는 의미를 담은 응답이다.
400 Bad Request에 대한 설명 (( http://tools.ietf.org/html/rfc2616#section-10.4.1 ))
The request could not be understood by the server due to malformed syntax.
403 Forbidden에 대한 설명 (( http://tools.ietf.org/html/rfc2616#section-10.4.4 ))
The server understood the request, but is refusing to fulfill it.
HTTP/1.1 개정판
그런데 HTTP/1.1 개정판에선 흔히 알려진대로가 거의 맞다. 403 Forbidden은 권한(authorization)에 대한 에러가 맞고, 400 Bad Request는 그냥 요청에 문제가 있어서 처리를 못하겠다(혹은 안하겠다)는 에러다.
400 Bad Request에 대한 설명 (( http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#section-6.5.1 ))
The server cannot or will not process the request, due to a client error (e.g., malformed syntax).
403 Forbidden에 대한 설명 (( http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#section-6.5.3 ))
The server understood the request, but refuses to authorize it.
요새 점점 RFC 2616보다 개정판을 따르는게 낫겠다는 생각이 들고 있다. 별 차이 없겠지 싶어서 그냥 RFC 2616을 따르고 있었는데, 의외로 이렇게 차이가 나는 부분이 있다. 어차피 개정판이라고 해봐야 설명만 고친거고 프로토콜의 요구사항 자체는 둘 다 같으니 동작에 문제를 일으키는 일은 없겠지.
그러네요 헤더에 이상한 값이 있어도 그런거 같더라고요 ! 400의 경우
좋아요좋아요
RFC 7230 3.2.1. Field Extensibility에 따르면, 서버가 모르는 헤더를 발견했을때는 그냥 무시하는게 맞고요.
만약 아는 헤더인데 값의 문법이 잘못된 경우에는 400 Bad Request도 괜찮을 것 같네요.
좋아요좋아요
에러코드 400 이 뜨면 어떻게 수정하나요?
좋아요Liked by 1명
서버가 충분히 친절하다면 응답 메시지에 에러의 이유가 적혀 있을 것입니다. 만약 그렇지 않다면 요청 메시지에 어떤 문제가 있는지 일일이 검토해보거나 (가능하다면) 서버 담당자에게 문의를 해 볼 수도 있을 것입니다.
좋아요좋아요
에러400 관련 문의입니다. 스마트폰을 초기화 하고서 나서 이런 error 400 이 나오던데, 어느 서버담당자한테 문의 해야 하나요?
좋아요좋아요