서버는 접수했다. 양식은 벌써 다음 사람 차례다.

요약

• 1997년 HTTP/1.1의 205 Reset Content는 서버가 요청을 처리했으며 클라이언트가 그 요청을 보낸 문서 화면을 초기 상태로 돌려야 한다고 설명했다.
• 응답에는 새 본문이 없다. 2014년과 2022년 문서는 반복 입력의 용도와 빈 응답의 명확한 끝을 설명했다.

창구에 작성한 신청서를 내민다. 직원은 서류를 파일에 넣고 곧바로 빈 양식을 다시 밀어준다. 방금 한 일은 끝났고, 책상은 다음 일을 기다린다. 초기 HTTP에는 이 빠르고 조금은 냉정한 접수 절차를 위한 번호가 있었다. 205 Reset Content다.

1997년 1월의 RFC 2068은 서버가 요청을 이행했고, 사용자 에이전트가 그 요청을 일으킨 문서 보기를 재설정해야 한다고 썼다. 예시는 입력 양식이다. 사람이 내용을 적어 보내면 입력 칸을 비워 다음 항목을 쉽게 넣는다. 서버의 완료와 화면의 재준비가 하나의 상태 코드로 이어졌다.

여기서 되돌아가는 것은 작업 결과가 아니라 사용자의 작업면이다. 보낸 데이터는 이미 처리된 요청에 속한다. 브라우저는 입력 공간을 처음 상태로 돌린다. RFC 2068은 205 응답에 엔터티를 넣지 못하게 했다. 서버는 새 페이지를 건네지 않고 기존 화면을 어떻게 정리할지 알려줬다. 파일에 들어간 서류는 그대로 있고, 다음 서류를 쓸 책상만 말끔해진다.

1999년 6월의 RFC 2616도 양식을 비운 뒤 다시 입력하는 장면을 유지했다. 바로 옆의 204 No Content는 현재 화면을 그대로 둔다. 둘 다 새 본문을 보내지 않지만, 다음 동작이 갈라진다. 205는 같은 종류의 입력을 거듭하는 사람을 위한 박자를 갖고 있다. 한 건을 마치고, 칸을 비우고, 다음 건으로 넘어간다.

2014년의 RFC 7231은 복원할 위치를 더 정확히 적었다. 화면은 원 서버에서 받았던 원래 상태로 돌아가야 한다. 입력 공간은 양식뿐 아니라 메모장이나 캔버스일 수도 있다. 사람은 그곳에서 입력하거나 조작하고, 결과를 제출한 뒤, 다음 작업을 위해 시작점으로 돌아온다. HTTP 규격은 데이터 교환 뒤에 이어질 사람의 반복 업무까지 다루고 있었다.

빈 응답에도 네트워크상의 끝은 분명해야 한다. 2014년 문서는 205에 페이로드가 없어야 한다고 정하고 세 가지 표시 방법을 열거했다. Content-Length: 0을 보내거나, 길이 0인 마지막 청크로 분할 전송을 끝내거나, 헤더 뒤에서 연결을 닫는다. 클라이언트는 메시지가 끝난 지점을 알아야 다음 메시지를 읽을 수 있다. 깨끗해진 입력 화면 뒤에는 이렇게 정확한 바이트 경계가 있다.

2022년의 RFC 9110은 핵심 배치를 이어받았다. 요청은 이행됐고, 사용자 에이전트는 문서 보기를 원래대로 돌리며, 응답에는 추가 콘텐츠가 없다. 화면의 모양이 달라져도 제출 다음에 다시 입력해야 하는 일은 남는다. 서버는 완료된 결과를 보관하고, 클라이언트는 다음 일의 자리를 마련한다.

205에는 창구 직원 같은 건조한 유머가 있다. “접수됐습니다. 다음 양식입니다.” 그러나 그 성급함은 역할을 정확히 나눈다. 완료된 요청은 서버에 남고, 입력 칸은 사람에게 돌아온다. 인터넷의 역사는 때로 거창한 새 화면보다 빈 칸 하나를 빨리 내주는 기술에 숨어 있다.