사용자가 보낸 데이터를 처리하는 처리 파일이 있는데, 그 전에는 클라이언트 측 데이터가 변경되지 않도록 클라이언트의 입력을 예상 값과 비교합니다.
나는 HTTP 상태 코드에 대해 많이 모른다고 말할 수 있지만 이에 대해 몇 가지 조사를 했고 예상치 못한 입력 처리에 가장 적합한 것을 선택했습니다. 그래서 나는 다음을 생각해 냈습니다.
400 Bad Request: The request cannot be fulfilled due to bad syntax
417 Expectation Failed: The server cannot meet the requirements of the Expect request-header field
이제 어떤 것을 사용해야 할지 확신할 수 없습니다. 400 Bad Request가 많이 사용되는 것을 보았지만 설명을 통해 알 수 있듯이 오류는 잘못된 입력이 아닌 존재하지 않는 요청으로 인한 것입니다.
반면에 417 Expectation Failed는 내 용도에 딱 맞는 것 같지만 이전에 이 헤더 상태를 보거나 실험해 본 적이 없습니다.
여러분의 경험과 의견이 필요합니다. 정말 감사합니다!
양식/프로세스 페이지 초안 및 내 실험에 대한 자세한 내용을 보려면 다음을 따르세요.이 링크.
추가: 제가 이것을 원하는 또 다른 이유는 Google 조작을 방지하기 위한 것입니다. 이는 백엔드뿐만 아니라 게스트/사용자 상호 작용이 표시되고 페이지 콘텐츠가 표시되는 프런트엔드에서도 사용됩니다.
나는 * 존재하거나 존재하도록 허용된 페이지에 대해 200 OK 또는 403 Forbidden 상태 코드를 부여하는 것이 유효하다고 믿습니다.
*추가 2: 지금 417과 100을 조사한 결과 여기에서 내가 하려는 작업(적어도 업로드 처리 사례에만 해당)과 유사하다는 것을 알았습니다. http://benramsey.com/blog/2008/04/http-status-100-continue/
- 즉:*X 사이트로 연결되는 웹페이지http://www.example.com/page.php?query=lol&query2=failHTTP 헤더가 OK로 제공되므로 Google에서 색인을 생성합니다.
내가 선택한 솔루션:
실제로 404는 내가 다시 끝날 수도 있는 것입니다. 나는 단지 HTTP가 제공하는 것보다 다른 솔루션을 원했지만 지금까지는 404가 여전히 이에 사용할 수 있는 최고의 솔루션인 것 같습니다. 모두 감사합니다. 제 질문에 대한 답을 찾았습니다.
답변1
GET 요청의 매개변수가 올바르지 않은 경우 표준적으로 해야 할 일은 404(찾을 수 없음) 또는 200(정상)을 다시 보내는 것입니다.
GET 요청을 사용하는 RESTful 방법은 리소스를 쿼리하는 것입니다(무언가 가져오기). 따라서 필수 매개변수가 기존 리소스와 일치하지 않는 경우(불완전하여) URI에서 쿼리한 리소스를 찾을 수 없다고 정확하게 말할 수 있습니다.
실제로 브라우저가 404 페이지를 무시하고 자신의 페이지로 대체하는 것과 같은 상황을 피하려면(IE 9 및 10을 보고 있습니다) 200을 사용하는 것이 좋습니다. 애플리케이션을 리소스로 생각한다면 200이 적절합니다. 애플리케이션에 쿼리를 실행하고 결과가 반환되었습니다(우연히 오류였지만 HTTP 수준에서는 발생하지 않음). 그러나 이 사용은 별로 RESTful하지 않습니다.
답변2
오류 417는 클라이언트가 Expect서버가 이행할 수 없는 HTTP 헤더를 보낸 경우에만 발생해야 하며, 이는 요청에서 애플리케이션의 "예상 입력"과 어떤 방식으로도 관련되지 않습니다. 사용하지 마십시오.
반면, 400HTTP 요청에 서버가 이해하지 못하는 잘못된 구문이 있는 경우에만 오류를 보내야 합니다.
400이 중 어느 것도 응용 프로그램 논리의 유효성 검사 실패에는 실제로 적합하지 않지만 조금 더 적합하다고 생각합니다 .
403스택 오버플로에 대한 질문에 사용하려고 고려하고 있던 오류가 제 생각에는 최선의 선택입니다 .
방금 $_GET에서 예상 값을 찾을 수 없을 때 403 Forbidden 헤더를 사용했지만, 생각해 보면 실제로는 로그인이 필요한 작업이 아닙니다. (물론 사용자는 관리자를 보려면 로그인해야 합니다.) 패널), 예상치 못한 값 입력에 가깝습니다.
401인증이 필요할 때 활용되는 응답 코드인 를 생각하고 계십니다 . 403요청에 대한 일반적인 거부입니다. 이는 정확히 원하는 것과 같습니다.
이 모든 것은 응답 코드를 반환한다고 가정합니다 . API에는 적합하지만 사용자 대상 HTML 페이지의 경우 본문에 오류 정보가 포함된 4xx메시지를 보내고 싶을 가능성이 높습니다 .200
답변3
나는 당신이 무엇을 하고 있는지 잘 알 수 없지만 당신이 고려하지 않았을 수도 있는 추가 옵션이 있습니다 - 200 - OK. 그 이유는 데이터를 올바르게 수신했기 때문입니다. 문제는 해당 데이터가 애플리케이션에 유효하지 않기 때문이며 실제로 HTTP 프로토콜에 문제가 있는 것은 아닙니다.
관련 RFC는 다음과 같습니다.RFC2616. 400을 사용할 수 있지만 클라이언트에게 rfc에서 데이터를 수정할 수 있는 기능을 제공해야 합니다.
10.4.1 400 잘못된 요청
잘못된 구문으로 인해 서버에서 요청을 이해할 수 없습니다. 클라이언트는 수정 없이 요청을 반복해서는 안 됩니다.
417에 관해 RFC는 다음과 같이 말합니다.
10.4.18 417 예상 실패
Expect 요청 헤더 필드(14.20절 참조)에 주어진 기대를 이 서버가 충족할 수 없거나, 서버가 프록시인 경우 서버는 다음 홉 서버가 요청을 충족할 수 없다는 명확한 증거를 가지고 있습니다. .
따라서 예상 헤더를 사용하지 않는 경우 이 응답을 사용해서는 안 됩니다.