요약

  • 1991년 World Wide Web을 위해 기술된 원조 HTTP는GET요청 한 줄을 보내면 서버가 HTML 문서를 반환하고, 연결을 닫음으로써 문서의 끝을 알리는 방식이었습니다.
  • 이 간결한 교환에는 상태 줄이나 헤더가 없었습니다. 설계 노트 자체에 따르면 오류는 문서 형태로 돌아왔고, 텍스트를 읽어보기 전에는 성공과 구분할 수 없었습니다.
  • HTTP는 이후 버전화된 요청, 헤더, 상태 코드를 추가하면서도 호환성을 위해 단순 형식을 유지했습니다. 남아 있는 흔적은 HTTP/0.9가 얼마나 널리 사용되었는지를 재는 척도가 아니라 의도적인 호환성 경계입니다.

페이지가 곧 전체 응답이었다

World Wide Web의 1991년 구현에서 대화는 클라이언트가 서버에 연결을 연 뒤 시작되었습니다. 주소에 포트가 없으면 클라이언트는 80번 포트를 사용했습니다. 그런 다음GET과 문서 주소를 담은 한 줄을 보냈습니다. 서버는 HTML 텍스트 스트림으로 답했고, 문서를 모두 보내면 연결을 닫았습니다. 페이지 앞에 별도의 상태 줄도 없었고 뒤에 헤더 블록도 없었습니다. 첫 바이트부터 문서에 속했습니다.

이는 모든 페이지를 보이지 않는 HTTP 봉투가 감싸는 프로토콜이 아니었습니다. Tim Berners-Lee의 보존된 설명은 응답을 HTML 메시지라고 부르고, 연결 종료가 이를 끝낸다고 밝히며, 서버가 읽을 수 있는 HTML 오류 텍스트를 보낼 수 있다고 설명합니다. 같은 설명은 대가를 직접 짚습니다. 텍스트 자체를 통해서만 오류 응답과 만족스러운 응답을 구분할 수 있었다는 것입니다. 브라우저는 받은 페이지를 표시할 수 있었지만, 전송 형식 자체는 기계가 읽을 수 있는 “찾을 수 없음”, 리디렉션, 서버 오류 코드를 제공하지 않았습니다.

1992년 6월 요약은 이 설계상 절충을 분명히 드러냈습니다. 브라우저는 명령 하나, 즉GET과, 이름 지정된 색인을 위한 키워드를 포함할 수 있는 문서 식별자를 보냈습니다. 서버는 브라우저에 대한 상태를 보관하지 않았습니다. 응답은 HTML이나 일반 텍스트일 수 있었고, 그 응답 자체에 메뉴, 검색 결과 목록, 문서가 담길 수 있었습니다. 요약은 단순성을 높이 평가했습니다. 서버에서 오는 것은 마크업된 텍스트 외에 아무것도 없었다는 점입니다. 그러면서도 빠진 경계를 지목했습니다. HTTP 정보, 문서 내용, 문서 종류 사이에 어휘상의 구분이 없었고, 오류 메시지는 그저 문서였으며 독자가 무시할 수도 있었습니다.

이 모호성은 초기 서버가 흔히 실패했거나 사용자가 오류 페이지를 이해할 수 없었다는 증거가 아니라 메시지 형식의 속성이었습니다. 사람은 본문을 읽을 수 있었습니다. 프로그램은 살펴볼 상태 필드가 없었습니다. 그리고 응답이 연결 종료로 끝났기 때문에, 프로토콜은 문서의 정상적인 끝과 중단된 교환의 종료를 같은 사건으로 표현했습니다. 이 경계는 클라이언트에게 스트림이 멈췄다고만 알렸고, 그 이유는 말하지 않았습니다.

초기 설계는 정적 페이지에만 국한되지도 않았습니다.ISINDEX요소는 브라우저가 문서 식별자 뒤에 키워드를 붙여 질의를 구성하도록 신호할 수 있었고, 서버는 HTML 검색 결과 목록을 반환할 수 있었습니다. Berners-Lee의 1991년 HTTP 역할 설명은 색인 검색, 형식 협상, 다른 서버로의 참조까지 정보 접근 프로토콜에 필요한 능력으로 꼽았습니다. 이들은 더 넓은 설계의 목표였으며, 한 줄짜리 단순 교환이 이미 제공하던 기능으로 오해해서는 안 됩니다.

단순 응답이 바뀐 이유

1992년 12월까지 공개www-talk논의는 더 완전한 프로토콜로 가는 제안된 경로를 보여줍니다. Berners-Lee는 새 서버들이 기존의GET <url>요청을 계속 인식해야 한다고 썼습니다. 클라이언트는 같은 줄에 버전 토큰을 추가하고, 이어서From,Accept,Accept-Encoding같은 헤더를 붙일 수 있었습니다. 그의 예시 응답에는 버전, 응답 필드, MIME 콘텐츠 유형, 지원 메서드가 포함되어 있었습니다. 이는 최종 전송 기록이나 배포 증명이 아니라 제안이었지만, 설계 문제가 열리기 시작했음을 보여줍니다. 응답은 자신의 내용뿐 아니라 자신에 대한 정보도 담아야 했습니다.

1996년에 정보성 RFC로 공개된 RFC 1945는 이후 두 형식을 모두 기술했습니다. 단순 요청은 헤더 필드 없이GET하나와 URI뿐이었고, 단순 응답은 엔티티 본문뿐이며 서버가 연결을 닫으면 끝났습니다. 더 완전한 응답은 상태 줄로 시작해 응답 헤더와 엔티티 헤더를 포함할 수 있었습니다. 이 RFC는 특히 단순 요청이 서버가 반환된 미디어 유형을 식별하는 것을 막는다고 경고했습니다. 구형 형식을 인식 가능하게 유지한 것은 최신 HTTP 시스템이 더 이른 클라이언트와 서버를, 같은 메시지를 보냈다고 가장하지 않고도 처리할 수 있게 해 주었습니다.

시간 순서가 중요합니다. RFC의 회고적 정의는 호환성에 대한 유용한 기술이지, 1991년에 “HTTP/0.9”가 별도로 비준된 표준이었다는 증거가 아닙니다. Berners-Lee는 나중에 Nicola Pellow의 라인 모드 브라우저를 포함한 최초의 웹 서버·클라이언트 소프트웨어가 1991년 여름 고에너지 물리학 커뮤니티에, 이어서 하이퍼텍스트와 NeXT 커뮤니티에 도달했다고 회상했습니다. 또한 URI, HTML, HTTP 명세를 토론과 채택을 장려하기 위해 첫 서버에 공개했다고 말했습니다. 이 자료들은 프로토콜을 실험적 상황 속에 놓아줄 뿐, 각 메시지 형식을 사용한 설치 수를 세지는 않습니다.

문서만 돌려주는 응답은 작은 시스템을 이해 가능하게 만들었습니다. 자원을 요청하면 브라우저가 보여줄 수 있는 자료를 받는 것입니다. 한계는 클라이언트가 응답을 프로토콜 사건으로 다뤄야 할 때 드러났습니다. 상태 줄이 없으면 HTML 오류와 HTML 페이지가 교환 안에서 같은 자리를 차지했습니다. HTTP의 더 완전한 메시지는 결과, 메타데이터, 콘텐츠 사이에 기계가 읽을 수 있는 경계를 더했습니다. 구형 응답은 이후 프로토콜도 여전히 인식할 수 있는 단순 형식으로 남았습니다.

출처