rfc6265

Evergreen Note

Question :: 這篇文章主要在說什麼?

Answer :: 文章主要在研究 RFC 6265 - HTTP State Management Mechanism。文章是在定義 HTTP Cookie and Set-Cookie header fields 規範。

Summary

RFC 6265 - HTTP State Management Mechanism 是在定義 HTTP Cookies and Set-Cookie header fields。Cookie 是 Server / Client 資料交互的方法之一，是 developers of cookie- generating servers 和 developers of cookie-consuming user agents 需要關心的重要議題。

第四章節在說明 Set-Cookie header fields 規範以及重要屬性 ([[internet-rfc-6265-server-requirements]])。

Note

原文 :: rfc6265

Abstract

This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK]

Table of Contents

 11. Introduction
 22. Conventions
 3   2.1. Conformance Criteria
 4   2.2. Syntax Notation
 5   2.3. Terminology
 63. Overview
 7   3.1. Examples
 84. Server Requirements
 9   4.1. Set-Cookie
10        4.1.1. Syntax
11        4.1.2. Semantics (Non-Normative)
12   4.2. Cookie
13        4.2.1. Syntax
14        4.2.2. Semantics
155. User Agent Requirements
16   5.1. Subcomponent Algorithms
17        5.1.1. Dates
18        5.1.2. Canonicalized Host Names
19        5.1.3. Domain Matching
20        5.1.4. Paths and Path-Match
21   5.2. The Set-Cookie Header
22        5.2.1. The Expires Attribute
23        5.2.2. The Max-Age Attribute
24        5.2.3. The Domain Attribute
25        5.2.4. The Path Attribute
26        5.2.5. The Secure Attribute
27        5.2.6. The HttpOnly Attribute
28   5.3. Storage Model
29   5.4. The Cookie Header
306. Implementation Considerations
31   6.1. Limits
32   6.2. Application Programming Interfaces
33   6.3. IDNA Dependency and Migration
347. Privacy Considerations
35   7.1. Third-Party Cookies
36   7.2. User Controls
37   7.3. Expiration Dates
388. Security Considerations
39   8.1. Overview
40   8.2. Ambient Authority
41   8.3. Clear Text
42   8.4. Session Identifiers
43   8.5. Weak Confidentiality
44   8.6. Weak Integrity
45   8.7. Reliance on DNS
469. IANA Considerations
47   9.1. Cookie
48   9.2. Set-Cookie
49   9.3. Cookie2
50   9.4. Set-Cookie2
5110. References
52   10.1. Normative References
53   10.2. Informative References
54Appendix A. Acknowledgements

Introduction

This document defines the HTTP Cookie and Set-Cookie header fields. Using the Set-Cookie header field, an HTTP server can pass name/value pairs and associated metadata (called cookies) to a user agent. When the user agent makes subsequent requests to the server, the user agent uses the metadata and other information to determine whether to return the name/value pairs in the Cookie header.

Although simple on their surface, cookies have a number of complexities. For example, the server indicates a scope for each cookie when sending it to the user agent. The scope indicates the maximum amount of time in which the user agent should return the cookie, the servers to which the user agent should return the cookie, and the URI schemes for which the cookie is applicable.

For historical reasons, cookies contain a number of security and privacy infelicities. For example, a server can indicate that a given cookie is intended for "secure" connections, but the Secure attribute does not provide integrity in the presence of an active network attacker. Similarly, cookies for a given host are shared across all the ports on that host, even though the usual "same-origin policy" used by web browsers isolates content retrieved via different ports.

There are two audiences for this specification: developers of cookie- generating servers and developers of cookie-consuming user agents.

To maximize interoperability with user agents, servers SHOULD limit themselves to the well-behaved profile defined in Section 4 when generating cookies.

User agents MUST implement the more liberal processing rules defined in Section 5, in order to maximize interoperability with existing servers that do not conform to the well-behaved profile defined in Section 4.

This document specifies the syntax and semantics of these headers as they are actually used on the Internet. In particular, this document does not create new syntax or semantics beyond those in use today. The recommendations for cookie generation provided in Section 4 represent a preferred subset of current server behavior, and even the more liberal cookie processing algorithm provided in Section 5 does not recommend all of the syntactic and semantic variations in use today. Where some existing software differs from the recommended protocol in significant ways, the document contains a note explaining the difference.