URL의 매개 변수와 <form method = "get">의 매개 변수간에 차이가 있습니까?

Question

URL 매개 변수와 POST 매개 변수의 차이점을 알았습니다. URL이 너무 길면 일부 브라우저가 오작동 할 수 있으므로 URL에 매개 변수 수백 개를 넣는 것은 좋지 않습니다. GET 요청에 응답하십시오.

토론을 위해 다음 웹 응용 프로그램을 가정 해 봅시다. 사용자가 일련의 (수 백 가지) X, Y 좌표를 입력 할 수 있습니다. 서버는이를 차트로 구성하여 이미지로 반환합니다.

이것은 분명히 idempotent operation의 예이므로 HTTP spec에 따르면 GET 작업으로 구현하는 것이 좋습니다. 그러나 모든 매개 변수가 포함 된 URL은 너무 길어질 수 없으므로 작성할 수 없습니다. < 양식 메서드 = "get"> 많은 매개 변수를 처리 할 수 ​​있습니까?

나는 또한 < 양식 메서드 = "get"이라고 들었습니다. >은 URL에 매개 변수를 배치하는 것과 완전히 동일합니까? 이제, 일부 브라우저 또는 전체 HTTP 프로토콜에 대해 사실입니까? 요청에 최대 길이가 있습니까?

Answer 1

HTTP 사양은 제한 사항을 설정하지 않지만 브라우저와 서버는 제한 사항을 설정합니다. 자세한 내용은 here을 참조하십시오.

위의 제한 사항이 적용되므로 양식에서 메서드가 GET으로 설정된 경우 브라우저에서 긴 URL을 만듭니다.

Answer 2

브라우저가 실제로하는 일은 양식 입력에서 매우 긴 URL을 작성하는 것입니다. 따라서 URL과 양식 Method = "GET"사이에는 차이가 없습니다. 둘 중 하나를 선택하면 동일한 URL이로드됩니다.

Answer 3

나는 또한 양식 메서드 = "get"이라고 들었습니다. >은 URL에 매개 변수를 배치하는 것과 완전히 동일합니까? 여기에, 사실

은 최대 길이는 요청에 거기에 대응하는 RFC section

입니까?

spec은 "HTTP 프로토콜은 URI의 길이에 선험적 인 제한을 두지 않습니다."라고 말합니다.

그러나 Internet Explorer 6에는 2,083 자의 제한이 있습니다. 다른 브라우저에서는 더 많은 문자를 사용할 수 있지만 해당 경로를 선택하면 기본적으로 ie6 용으로 디자인해야합니다.

Answer 4

양식 메소드 = 가져 오기 모든 양식 입력을 URL에 입력합니다.

브라우저의 URL 길이가 최대 인 것은 사실입니다. 그것은 브라우저에서 브라우저로, 그리고 분명히 브라우저 버전에서 브라우저 버전으로 바뀝니다.

가능한 경우 양식에 POST를 사용하는 것이 좋습니다. 브라우저가 단순히 요청을 보내기 전에 URL에 GET 양식을 변환으로

HTH

Answer 5

GET 및 URL? 이름 = 값 &은 ... 같은 일이다.

URL의 최대 길이는 브라우저 및 서버 수준에서 결정되므로 주어진 브라우저/서버의 경우 URL의 최대 길이는 두 가지 중 작은 값입니다.

This post이 얻을 및 사후 그러나 상황에서 같은 당신이 자주 쉽게 더 복잡한을 저장하는 것입니다 묘사에 대한 질문에 대한 답변하지 않습니다 URL이

Answer 6

현재 최대 길이의 좋은 목록을 가지고 데이터를 서버에 저장하고 매번 URL에 넣지 않고 세션 ID 또는 사용자 계정과 연결합니다. 그런 다음 해당 세션 식별자를 쿠키 또는 url 매개 변수로 사용하여 이미지를 검색 할 수 있습니다.

이렇게하면 요청한 이미지를 캐시하여 사용자가 특정 차트를 다시보고 싶을 때마다 재생성 작업을 수행하지 않아도됩니다.

Answer 7

아니요, 서버는 URL에 매개 변수를 넣는 것과 GET 메서드로 FORM을 사용하는 것의 차이점을 볼 수 없습니다. 따라서 매개 변수가있는 URL이 너무 길면 FORM을 GET 메서드와 함께 사용하면 도움이되지 않습니다.

POST 또는 GET은 주로 의미에 맞게 선택해야합니다. GET은 "안전한"동작을위한 것입니다. 즉, 사용자는 GET 요청에 의해 수행 된 작업에 대해 책임을지지 않아야합니다. POST 메소드는 사용자가 책임 져야하는 조작에 사용됩니다.

검색 기능이 POST를 사용하는 경우와 같이 매우 실망 스럽습니다. 사용자는 단순한 쿼리로 인해 검색이 "안전한"조작으로 수행되기를 기대하는 중요한 시스템 상태 —을 변경하지 않을 것으로 기대합니다.

반면 안전하지 않은 작업은 POST뿐만 아니라 GET 요청을 통해 액세스 할 수 있기 때문에 많은 취약점이 존재합니다. 이는 공격자가 합법적 인 사이트의 IMG 태그에 악성 "src"URL을 가져와야하는 XSRF와 같은 취약점에 기여합니다.

사용 사례에 따라 실제로 Ajax가 적절한 해결책 일 수 있습니다. 선택한 각 지점에 대해 GET 요청을 만들어 서버의 세션에 저장합니다. 사용자가 포인트 입력을 마쳤 으면 최종 GET 요청이 완성 된 제품을 검색합니다.

Answer 8

HTTP specification은 GET 요청의 매개 변수를 URI에 배치해야한다고 명시 적으로 요구하지 않습니다. POST를 사용하는 양식처럼 GET 요청에서 메시지 본문을 보내는 것이 합법적입니다.

그러나 브라우저는 GET 양식을 아주 좋은 이유로 캐싱합니다. 캐싱. GET 요청은 부작용없이 서버에서 처리 될 것으로 예상됩니다. 따라서 GET 요청에 대한 응답이 캐싱 될 수 있습니다. 이 성능 향상 옵션은 GET 요청에서 메시지 본문을 사용하기 시작하면 즉시 사라집니다.

차트 API를 디자인하려는 경우 Google을 살펴볼 수 있습니다. 그들은 이미 대중에게 아주 좋은 것을 제공합니다. 가능한 한 많은 정보를 URI 매개 변수에 묶는 방법을 배우기위한 용도로만 사용하더라도 한 번 볼만한 가치가 있습니다.