요약

  • MCI의 1994년 마켓플레이스 프로젝트는 주문, 청구, 배송 정보가 웹 요청을 넘나들며 유지되어야 했습니다. 팀은 넷스케이프의 초기 서버 측 제안을 거부하고 상태를 클라이언트에 저장하도록 요구했습니다.
  • 넷스케이프는 이 고객 요구를 일반 브라우저 기능으로 바꾸었습니다. 쿠키는 서버가 상태 값을 보내고, 브라우저가 이후 일치하는 요청에 그 값을 돌려줄 수 있게 했지만, 그것 자체로 브라우저를 쥔 사람이 누구인지 확인해 주지는 않았습니다.
  • RFC 2109는 이미 구현과 호환성에 의해 형태가 정해진 메커니즘을 사후에 표준화하려 했습니다. 표준 문서 자체도 사용자 통제, 읽을 수 있는 값, 암호화되지 않은 전송을 실제 한계로 인정했습니다.

장바구니가 무상태성을 제품 문제로 만들다

웹의 익숙한 요청-응답 패턴에는 실용적 공백이 있었습니다. HTTP 요청은 페이지를 요청하고 받을 수 있었지만, 다음 요청이 응용 프로그램의 이력을 자동으로 함께 실어 보내지는 않았습니다. 판매자는 그 이력을 자체 서버에 보관할 수도 있었지만, 그러면 브라우저가 사라진 뒤 남겨진 상태와 기록을 관리해야 했습니다.

MCI는 marketplaceMCI를 온라인 쇼핑 환경으로 만들고 있었습니다. 이 시스템은 MCI 브랜드 브라우저, 웹 서버, 주문을 접수하고 처리하는 판매자 서버, 지원과 판매자 계정용 백엔드 시스템을 결합하도록 설계되었습니다. 상업적 과제는 구체적이었습니다. 주문, 청구, 배송 정보를 일련의 요청을 통해 전달하는 것이었습니다.

그 중요한 설계 결정은 홀로 일한 발명가에 대한 통설이 아니라 이후 법정 기록에 나타납니다. 1994년 8월 10일, MCI는 상태를 서버에 두자는 넷스케이프의 초기 제안을 거부하고, 그 정보를 클라이언트 컴퓨터에 저장할 것을 요구했습니다. 이 기록은 일부 기술적 세부 사항에 대한 의견 차이는 남겨두면서, 그 일반적 요구 자체는 다툼이 없다고 서술합니다.

이 요구는 응용 프로그램의 단기 기억이 놓이는 위치를 바꾸었습니다. 브라우저가 서버 방문 사이에 작은 상태 객체를 보관하게 되는 것입니다. 넷스케이프 프로그래머 Lou Montulli가 이 문제에 배정되었습니다. Montulli는 나중에 HTTP의 세션 없는 특성을 위해 쇼핑 카트 방식을 고안하도록 요청받았다고 회상했지만, MCI가 그 구체적 고객이었다는 것은 기억하지 못했습니다. Marc Andreessen은 MCI 프로젝트가 결국 쿠키로 이어졌고, 넷스케이프가 이 기능을 일반 용도로 확장했다고 증언했습니다. 이런 증언들은 고객의 필요를 제품 결정과 연결해 주지만, 설계 역사의 모든 세부를 확정해 주지는 않습니다.

브라우저가 응용 프로그램 상태의 운반자가 되다

보존된 넷스케이프 명세는 이 메커니즘을 단순한 말로 설명합니다. 서버는 HTTP 응답과 함께 상태 객체를 돌려줄 수 있었습니다. 브라우저는 그것을 저장한 뒤, URL이 쿠키의 범위와 일치하는 이후 요청에 그것을 포함시킵니다. 값을 정하고 해석하는 것은 서버 응용 프로그램의 몫이었고, 브라우저의 역할은 그 값을 보존하고 돌려주는 것이었습니다.

이것만으로도 응용 프로그램은 장바구니 참조, 등록 값 또는 선호 설정을 요청에서 다음 요청으로 옮길 수 있었습니다. 그러나 그것은 HTTP를 끊임없이 연결된 프로토콜로 만들지 않았습니다. 페이지 자체가 방문자마다의 장바구니를 담아야 하도록 요구하지도 않았는데, 이 점은 웹 캐싱에서 중요했습니다. 그리고 서버가 일을 그만두게 하지도 않았습니다. 응용 프로그램은 여전히 돌려받은 값을 다른 곳에 보관하는 자신의 기록에 대한 키로 쓸 수 있었습니다.

넷스케이프 문서는 자신을 예비 명세라고 부르며 독자에게 신중하게 사용할 것을 권했습니다. 초기 규칙에는 호스트나 도메인, 경로, 만료, 보안 전송 같은 세부 사항이 담겼습니다. 이것들은 브라우저가 언제 상태를 돌려줄지 정하는 실용적 경계였습니다. 사용자의 이름, 동의, 계속 접속 여부에 대한 증명은 아니었습니다.

기록에 따르면 쿠키 관련 임시 코드는 1994년 10월 3일 또는 4일에 넷스케이프의 소스 저장소에 들어갔고, 10월 6일과 13일에 이후 변경이 이루어졌습니다. 소송 당사자들은 발명이 실제로 실현된 정확한 날짜를 놓고 다투었습니다. 따라서 방어 가능한 연표는 여름의 설계와 고객 요구, 법원 기술에 따른 10월 초의 동작 코드, 그리고 넷스케이프 브라우저를 위해 일반화되는 기능입니다. 이것은 단일하고 다툼 없는 "발명의 날"이 아닙니다.

브라우저 제안 이후에 도착한 표준

1997년 2월, David Kristol과 Montulli는 RFC 2109, 즉 "HTTP State Management Mechanism"을 발표했습니다. 이 문서는Set-Cookie응답과Cookie요청을 기술하고, 그 교환을 표준 트랙 문법에 넣으려 했습니다. 문서는 넷스케이프의 원래 제안과의 호환성을 위한 역사 섹션을 명시적으로 포함했습니다. 따라서 표준화는 이미 퍼져 있는 코드와 동작을 수용하는 작업이기도 했습니다.

RFC 2109는 이 메커니즘의 한계를 이례적으로 분명히 드러냈습니다. 사용자 에이전트는 쿠키가 전송되고 보관되는지에 대한 통제를 사람에게 주어야 했습니다. 헤더 내용은 보호되지 않은 채 전송되므로 민감한 값이 노출되거나 변경될 수 있었습니다. RFC는 쿠키 값을 브라우저 관점에서 불투명하다고 불렀지만, 그것이 읽힐 수 있음도 인정했습니다. 로그인 예제에서는 먼저 사용자가 양식을 통해 자신을 확인하고, 그 뒤에 서버가 그 신원을 반영하는 쿠키를 돌려줍니다. 쿠키는 신원 확인 단계 이후에 응용 프로그램의 상태를 나릅니다. 그 교환 자체가 쿠키를 독립적인 신원 검증으로 만들지는 않습니다.

이 경계가 중요한 이유는, 브라우저가 보관한 값이 서비스에 유용하면서도 개인에 관한 약한 주장일 수 있기 때문입니다. 응용 프로그램이 어떤 값의 소지를 권한으로 취급하면, 지참자 방식의 세션 역량을 만들어낸 것입니다. 그 값을 획득한 누구든 범위와 수명 안에서 재사용할 수 있을지 모릅니다. 그것이 안전한지는 응용 프로그램이 그 값을 어떻게 발급하고, 보호하고, 만료시키고, 철회하는지에 달려 있는데, 이는 기본적인 쿠키 교환이 스스로 답해 주지 않는 문제입니다.

쿠키의 역사적 의미는 그 이름이 암시하는 것보다 신비롭지 않습니다. 쇼핑 흐름이 한 제품 팀에게 연속성이 어디에 머물지 정하도록 강요했습니다. 브라우저는 서버가 고른 상태의 운반자가 되었고, 고객 맞춤 요구는 재사용 가능한 기능이 되었으며, 이후 표준화 작업은 배치된 실무와의 호환성을 기록했습니다. 그 결과 웹 응용 프로그램은 서로 분리된 요청 사이에서 거래를 기억할 수 있었습니다. 그러나 쿠키는 브라우저를 그 뒤에 있는 인간 신원의 목격자로 만들지는 못했습니다.

출처와 한계