HTTP/1.0의 바디 수신은 특별히 어렵거나 하지 않다. 클라이언트가 지정한 콘텐츠가 그대로 저장될 뿐이다. 기본적으로 한 번 HTTP가 응답 할 때마다 한 파일밖에 반환하지 못하기 때문이다. 즉 응답의 본체를 지정한 바이트 수만큼 읽어오면 끝이다. HTTP/1.1에는 범위 엑세스라는 특수 한 요청 방법이 생겼다. 폼을 요청한 POST 전송에는 몇 가지 방식이 있다. 가장 단순한 전송방식은 HTML form 태그의 method를 POST로 지정하는 것이다. 그렇게 한다면 헤더로 Content-Type:application/x-www-form-urlencoded로 설정되어 있습니다. 그리고 이것과 함께 바디에 key-value로 전달받습니다.
HTML의 폼에서는 옵션으로 멀티파티 폼 형식이라는 인코딩 단순한 폼 보다는 복잡하지만, 옵션을 사용해서 파일을 보낼 수 있다.form 옵션으로 action을 POST로 지정하고 ectype 옵션에는 multipart/form-data으로 지정한다. 이것은 한 번의 요청으로 복수의 파일을 전송할 수 있으므로 받는 쪽에서 파일을 나눠야 한다. 헤더에는 Content-Dispostion이라는 항목이 추가 되는데 Content-Type의 멀티 버전이라고 보면 된다.
300번대로 하는 리디렉트는 몇 가지 제한이 있다. URL에는 2 천자 이내 라는 기준이 있고, GET의 쿼리로 보낼 수 있는 데이터의 양에 한계가 있으며, 데이터가 URL에 포함되므로 전송하는 내용이 엑세스 로그에 남을 우려등이다. 이러한 문제를 피하고자 종종 이용되는 방법이 HTML의 폼을 이용한 리디렉트다. 서버로부터는 리디렉트 할 곳으로 보내고 싶은 데이터가 input의 type 옵션 hidden태그로 기술된 HTML로 돌안다. 폼에서 보내는 곳이 리디렉트 할 곳이다. 브라우저가 HTML을 열면 로드 직후 발생하는 이벤트로 폼을 전송하므로 즉시 리디렉트해 이동하게 된다. 이 방법의 장점은 데이터 양의 제한이 없지만 단점으로는 순간적으로 빈 페이지가 표시되는것과 전환 버튼이 표시되긴 하나 자바스크립트가 비활성화 되어있으면 자동으로 전환되지 않는 다는 것이다.
서버와 클라이언트는 따로 개발되어 운용되므로 양쪽이 기대하는 형식이나 설정이 항상 일치한다고 할 수 없다. 통신 방법을 최적화하고자 하나의 요청안에서 서버와 클라이언트가 서로 최고의 설정을 공유하는 시스템이 콘텐츠 니고시에이션이다. 콘텐트 니고시에이션에는 헤더를 이용하는데 대상과 사용하는 헤더는 아래 네가지 이다.
콘텐츠 압축은 전송 속도 향상을 위한 것으로 1992년에 이미 정의되어 있었다. 콘텐츠 내용에 따라 다르지만 현재 일반적으로 사용되는 압축 알고리즘을 적용하면 텍스트 파일은 1/10크기로 압축된다. 같은 기호가 반복해서 나오는 JSON이라면 1/20정도로 압축 할 수 있다. 통신에 걸리는 시간보다 압축과 해제가 짧은 시간에 이뤄지므로 압축을 함으로써 웹페이지를 표시할 때 걸리는 전체적인 처리 시간을 줄일 수 있다. 콘텐츠 압축 니고시에이션은 모두 HTTP의 헤더 안에서 완료된다. 우선 클라이언트가 수용 가능한 압축 방식을 헤더에 지정하고 서버는 전송받은 목록 중 지원하는 방식이 있다면 그 방식으로 압축하거나 미리 압축된 콘텐츠를 반환한다. 구글은 gzip보다 효율이 더 좋은 새로운 압축 포맷 브로틀리를 공개했는데 현시점에서 파폭, 크롬, 엣지가 지원하고 있다. 인코딩으로 받아들일 수 있는 포맷으로 br을 지정해 요청을 보내고, 서버도 지원할 경우 브로틀리 압축으로 고속화가 이뤄진다. 클라이언트가 지원하지 않는다면 br는 전송되지 않으며, 서버가 지원하지 않으면 양쪽에서 다 지원하는 다른 인코딩으로 대체 된다. HTTP 1.0은 지금의 고속화 방식과는 대조적으로 Accpet-Encoding에 헤더를 부여하고 그런 다음 클라이언트에서 무언가를 업로드 할떄 Content-Encoding을 부여한다. 무압축을 뜻하는 identity도 사용할 수 있다.