javascript - 가져오기 및 게시는 단지 규칙인가요?

예를 들어 get이 멱등성이 있고 안전하다고 가정해 보겠습니다. 이것이 단지 규칙이라는 뜻인가요? 코드를 통해 get을 사용할 수도 있습니다(멱등성이 없고 안전하지 않음).

답글 내용:

예를 들어 get이 멱등성이 있고 안전하다고 가정해 보겠습니다. 이것이 단지 규칙이라는 뜻인가요? 코드를 통해 get을 사용할 수도 있습니다(멱등성이 없고 안전하지 않음).

답변이 꽤 많고, 다양한 의견이 있어서 엄밀히 조사해 보기로 했습니다

첫 번째 결론은 GET 및 POST의 보안 및 멱등성 측면에서 이는 단순한 규칙이 아니라 표준이지만 표준에서는 보안 및 멱등성에 대한 제약이 없다는 것입니다

이 문제를 해결하기 위해 RFC 7231 문서를 파헤쳐보니 기존 RFC 2616이 6개의 프로토콜 설명인 RFC7230 - RFC7235로 대체되었습니다. 메소드 정의에 대해서는 RFC 7231에 있습니다.

https://tools.ietf.org/html/r...

주체가 우려하는 보안 방식과 멱등성 방식에 대해서는

RFC 7231의 4.2.1 및 4.2.2장에서는 "안전한 메서드"(안전한 메서드)와 "멱등성 메서드"(멱등성 메서드)가 무엇인지 명확하게 정의합니다.

그러면 RFC에 정의된 표준에서 보안 방법의 정의는 (저만의 느슨한 번역)

요청 메소드는 정의된 의미가 본질적으로 읽기 전용인 경우 "안전한" 것으로 간주됩니다. 즉, 클라이언트가 안전한 메소드를 적용한 결과 원본 서버의 상태 변경을 요청하지도 예상하지도 않습니다. 마찬가지로, 안전한 방법을 합리적으로 사용한다고 해서 원본 서버에 피해나 재산 손실 또는 비정상적인 부담이 발생할 것으로 예상되지는 않습니다.

요청 메서드는 본질적으로 읽기 전용이거나 클라이언트가 원본 서버 리소스에 메서드를 적용하고 상태가 변경될 때 어떤 변경도 예상하지 않는 경우 "안전"하다고 간주됩니다. 그리고 합리적인 보안 방법을 사용하면 서버에 어떠한 손상이나 속성 손실이 발생하거나 비정상적인 부하가 발생하지 않습니다

안전한 메서드에 대한 이러한 정의는 잠재적으로 해로울 수 있는 동작, 완전히 읽기 전용이 아니거나 안전한 메서드를 호출하는 동안 부작용을 일으키는 동작을 구현에 포함하는 것을 막지는 않습니다. 예를 들어, 대부분의 서버는 방법에 관계없이 모든 응답이 완료될 때 로그 파일에 액세스하기 위해 요청 정보를 추가하며 이는 로그 저장 공간이 부족하더라도 안전한 것으로 간주됩니다. 마찬가지로 웹에서 광고를 선택하여 시작된 안전한 요청은 광고 계정에 비용을 청구하는 부작용이 있는 경우가 많습니다.

이 안전한 방법의 정의는 결과에 해를 끼치거나 완전히 읽기 전용이 아니거나 다른 부작용을 일으키는 동작의 구현을 막지는 않습니다. 그러나 중요한 것은 (이러한 변경이 발생할 경우) 고객이 해야 한다는 것입니다. level 요청이 없다는 것(즉, 요청 당시에는 예상하지 못한 일)이라고 하므로 클라이언트는 책임을 지지 않습니다. 예를 들어 대부분의 서버는 각 요청 후에 액세스 로그에 요청 정보를 기록합니다. 그러나 일부 요청이 무엇이든 (겉으로는) 안전한 로깅 동작조차도 서버 충돌을 일으킬 수 있습니다. 마찬가지로 웹에서 광고에 대한 안전한 요청은 종종 광고 계정, 즉 청구에 부작용을 일으킬 수 있습니다. 🎜>

본 사양에서 정의한 요청 메소드 중 GET, HEAD, OPTIONS, TRACE 메소드는 안전하다고 정의되어 있습니다.

이 요청 메소드의 정의에 따라 GET, HEAD, OPTIONS 및 TRACE 메소드는 안전하다고 정의됩니다

멱등성 방법의 정의는 (저만의 느슨한 번역도 첨부합니다)

해당 메소드를 사용하는 여러 개의 동일한 요청이 서버에 미치는 의도된 효과가

단일 요청 메소드에 대한 효과와 동일한 경우

요청 메소드는 "멱등성"으로 간주됩니다. 이 사양에 정의된 PUT, DELETE 및 안전한 요청 메서드
는 멱등원입니다.

요청 메서드는 다음과 같은 상황에서 멱등하다고 간주됩니다. 요청이 단일 요청에서처럼 여러 요청에서 동일한 효과를 생성하는 경우 정의된 요청 메서드에는 PUT, DELETE 및 기타 "안전한" 메서드가 포함됩니다.

그래서 내 결론은 GET 및 POST의 보안 및 멱등성 측면에서 이는 단순한 규칙이 아니라 표준이지만 표준에서는 보안 및 멱등성에 대한 제약이 없다는 것입니다.

(아직 말하지 않았다는 뜻인 것 같네요)

== 성급한 원문답변 ==

합의 수준에도 도달하지 않았는데, 이것이 모범 사례라고 할 수 있습니다

이 작업을 수행하지 않는 웹사이트가 많습니다

그러나 이것이 우리가 이 모범 사례를 직접 구현하는 데 방해가 되는 것은 아닙니다.

GET POST는 단순한 규칙이 아닌 표준입니다.
협약과 표준의 차이는 시행 여부입니다.
계약의 이행 여부는 개인에 따라 다르며, GET POST를 기준으로 브라우저에서 충실하게 실행됩니다.
마지막으로 적어도 브라우저 환경에서는 GET과 POST 사이에 몇 가지 차이점이 있다는 것을 알게 될 것입니다.
예: GET은 양식 데이터를 전송할 수 없으므로 코드에서 GET을 완전히 POST를 대체하는 데 사용할 수 없습니다.

원래는 이렇게 사용하는 것이 일반적인 규칙이지만, 다른 용도로 사용하지 못하도록 하드코딩하지 않고 개인의 의견에 따라 유연하게 사용할 수 있습니다.

예, 제 생각에는 현재 특히 인기가 있는 RESTful이 실제로 http 프로토콜의 실제 구현이라고 생각합니다

이렇게 쓰지 않으면 동료들이 비웃을 것입니다. . .

CURD의 관점에서 볼 때 GET은 쿼리여야 하고 POST는 추가, 삭제, 수정이어야 한다고 규정한 사람은 없습니다. 그런 의미는 없습니다.

예, 컨벤션입니다.

젓가락, 숟가락, 포크로 식사하는 등 애플리케이션 계층 http 프로토콜의 방법.

이렇게 합의가 이루어지며, 합의의 의미는 합의입니다.
클라이언트와 서버를 직접 구현하는 경우 물론 이러한 계약을 무시할 수 있지만 일부 도킹을 수행하고 상대방이 계약을 준수하는 경우 이를 준수하지 않으면 통과가 허용되지 않습니다. 합의.

이것은 옹호자이자 표준입니다. 남용은 엄격히 금지됩니다. 모바일 앱과 웹사이트는 모두 데이터 기반 상위 계층 애플리케이션이며 통신은 http 프로토콜에 크게 의존하므로 모든 사람이 get과 post의 차이점을 최대한 이해하는 것이 좋습니다. 이는 단순한 규칙이 아니라 표준입니다. 규칙. 수정, 삭제, 생성 작업의 경우 get을 사용할 수 없다는 점이 가장 중요한 전제 조건입니다. 좀 더 깊게 말하면, 이것은 전문적인 능력을 보여주는 것입니다.

예를 들어 프런트엔드와 백엔드가 쿠키를 사용하여 상태를 저장하고 get을 사용하여 데이터를 추가하거나 수정하는 경우 CSRF는 웹사이트를 망칠 것입니다 = =