HTTP post 길이 제한??? (있다, 없다)

포스트 요청은  바디안에 정보가 들어가 있네요.

 

HTTP 1.1은 길이 제한없습니다. 그러나, Http 1.0은 길이 제한 있을 수 있습니다.

스펙상 content-length값을 받기 때문에 해당값이 없으면, 문제가 생길 수 있습니다. 또한 content-length값을 user agent가 어떻게 받아들이냐에 따라 달라질 것입니다. 즉, 유효값의 범위가 명확지 않기 때문에 user agent가 다르게 처리할 수 있는 것이지요.

그래서, http 1.0을 쓰는 브라우져 혹은 서버에서는 이번 문제가 있어서 파일이 큰 multi-part 전송에 에러가 날 수 있지요.(전혀 그런 얘기를 들어본 적 있어요..)

 

참조

http://news-wap.com/ResearchTopic/summer2003/j2ee/webcontainer/http.htm

 

POST 요청 메소드

POST 메소드는 일반적으로 동적 자원에 접근하기 위해 사용된다. 전통적으로, POST 요청은 요청 종속적인 정보를 전송하기 위한 수단이며 서버에게 상당히 많은 양의 복잡한 정보를 전송할 필요가 있을 때 사용한다.

POST 요청은 multi-part 메시지들을 요청 몸체 속으로 캡슐화한다. 예를 들어, 텍스트나 이진 파일들을 업로드하기 위해 POST 요청을 사용할 수 있다. 이와 유사하게, 직렬화 가능한 자바 객체나 미가공 바이트들을 웹 서버에게 보내기 위해 애플릿 내에서 POST 요청을 사용할 수 있다. 그래서 POST 요청은 요청 내용에 따라 폭넓은 선택을 제공한다.

GET과 POST 요청에는 차이가 있다. GET 요청에서는 요청 매개변수들이 요청 URL에 추가된 질의 문자열로 전송된다. 그러나, POST 요청에서는 요청 매개변수들이 요청의 몸체 내에 넣어져서 전송된다. 이것은 두 가지 결과를 초래한다. 먼저, GET 요청은 완전한 요청 정보를 URL 자체에 추가시키기 때문에, 브라우저들이 그 페이지를 북마크하여 나중에 재방문할 수 있도록 해준다. 타입과 요청 매개변수들이 얼마나 민감한 것인가에 따라 바람직할 수도 있고 그렇지 않을 수도 있다. 두 번째로, 어떤 서버들은 요청 URL의 길이에 대한 제한을 둘 수 있다. 이러한 제한은 요청 URL에 추가될 수 있는 정보의 양을 제한한다. 하지만 HTTP1.1은 최대 길이 제한을 두고 있지 않다. HTTP1.0의 서버/클라이언트는 매우 긴 길이에 대해서는 지원하지 않을 수도 있다.

 

 

참조 HTTP 1.0 스펙

http://raonism.net/CSdb/protocol/rfc1945-kr.html

 

8.3 POST

POST 요구 메시지는 메시지의 entity body에 포함되어 있는 자원을 Request-Line에 있는 Request-URI에 지정되어 있는 대로 서버에서 수용해달라고 요청할 때 쓰인다. 즉, POST는 다음과 같은 기능을 수행하기 위한 한 가지 방법으로 설계되었다.

• 기존 문서에 주석을 붙일 때 (오홋)!!!
• BBS 게시판, 메일링 리스트, 뉴스그룹, 또는 글 모음 장소 등에 글을 올릴 때
• 어떤 프로그램의 실행을 위해 form과 같은 특정 규격의 데이타를 넘겨줄 때
• 부가적인 동작을 통해 데이타베이스를 확장하고자 할 때

POST method에 의해 수행되는 실제 동작은 서버에 의해 결정되고 통상 Request-URI에 의해 좌우된다. 포스팅되는 대상은, 하나의 화일이 어느 디렉토리에 자리하게 되고 뉴스가 포스팅되는 뉴스그룹에 올려지고 레코드가 데이타 베이스가 등록되는 등과 똑같은 방식으로 지정된 URI에 놓이게 된다.

POST는 대상 서버에 하나의 자원으로서 생성될 필요가 없고 추후의 참조를 위해 접근 가능해야 할 필요도 없다. 즉, POST method에 의해 수행되는 동작은 포스팅 되는 entity가 URI에 의해 지정될 수 있는 자원이 아니어도 된다는 것이다. 이 경우의 적절한 응답 결과 코드는 200 (ok) 또는 204 (no content)가 될 것인데, 응답 메시지에 entity가 포함되어 있느냐 있지 않느냐에 따라 구분이 될 것이다. 어떤 자원이 대상 서버에 생성되는 경우라면 응답 결과 코드는 201(created)이 되어야 하고 상태 정보나 생성된 새 자원에 대한 정보를 알려주는 entity가 포함되어 있어야 한다.

HTTP/1.0의 모든 POST 요구 메시지에는 Content-Length가 반드시 있어야 하며, 서버가 이에 대한 정보를 확보하지 못하게 되면 400(bad request) 메시지를 응답해야 한다.

(A valid Content-Length is required on all HTTP/1.0 POST requests. An HTTP/1.0 server should respond with a 400 (bad request) message if it cannot determine the length of the request message's content.)

응용 프로그램에서는 POST 요구 메시지에 대한 응답을 캐싱할 필요가 없다. 왜냐하면 서버가 추후의 요구 메시지에 대한 응답으로서 똑같은 응답을 할 것인지 알 수가 없기 때문이다.

 

여기서 저는 Content-length 길이에 대해서는 다음에 대해서 나와있지만, 유효값(0이상의 값, 적용되지 않을 때 정책은 나와있음) 은 나와있지 않습니다.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

 

 

 

HTTP 1.1

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

 

POST파트에 HTTP 1.0의 Content내용이 빠져있습니다. 그래서 길이 제한이 없다고 하는군요.