Browse Prior Art Database

HTTP State Management Mechanism (RFC2965)

IP.com Disclosure Number: IPCOM000005158D
Original Publication Date: 2000-Oct-01
Included in the Prior Art Database: 2001-Aug-16
Document File: 27 page(s) / 56K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D. Kristol: AUTHOR [+2]

Abstract

This document specifies a way to create a stateful session with Hypertext Transfer Protocol (HTTP) requests and responses. It describes three new headers, Cookie, Cookie2, and Set-Cookie2, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal [Netscape], but it can interoperate with HTTP/1.0 user agents that use Netscape's method. (See the HISTORICAL section.)

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 6% of the total text.

Network Working Group D. Kristol Request for Comments: 2965 Bell Laboratories, Lucent Technologies Obsoletes: 2109 L. Montulli Category: Standards Track Epinions.com, Inc.

October 2000

HTTP State Management Mechanism

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

IESG Note

The IESG notes that this mechanism makes use of the .local top-level domain (TLD) internally when handling host names that don't contain any dots, and that this mechanism might not work in the expected way should an actual .local TLD ever be registered.

Abstract

This document specifies a way to create a stateful session with Hypertext Transfer Protocol (HTTP) requests and responses. It describes three new headers, Cookie, Cookie2, and Set-Cookie2, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal [Netscape], but it can interoperate with HTTP/1.0 user agents that use Netscape's method. (See the HISTORICAL section.)

This document reflects implementation experience with RFC 2109 and obsoletes it.

1. TERMINOLOGY

The terms user agent, client, server, proxy, origin server, and http_URL have the same meaning as in the HTTP/1.1 specification [RFC2616]. The terms abs_path and absoluteURI have the same meaning as in the URI Syntax specification [RFC2396].

Kristol Montulli Standards Track [Page 1]

RFC 2965 HTTP State Management Mechanism October 2000

Host name (HN) means either the host domain name (HDN) or the numeric Internet Protocol (IP) address of a host. The fully qualified domain name is preferred; use of numeric IP addresses is strongly discouraged.

The terms request-host and request-URI refer to the values the client would send to the server as, respectively, the host (but not port) and abs_path portions of the absoluteURI (http_URL) of the HTTP request line. Note that request-host is a HN.

The term effective host name is related to host name. If a host name contains no dots, the effective host name is that name with the string .local appended to it. Otherwise the effective host name is the same as the host name. Note that all effective host names contain at least one dot.

The term request-port refers to the port portion of the absoluteURI (http_URL) of the HTTP request line. If the absoluteURI has no explicit port, the request-port is the HTTP default, 80. The request-port of a cookie is the request-port of the request in which a Set-Cookie2 respo...