Context Navigation

draft-ietf-httpbis-p3-payload-10.txt @ 956

Last change on this file since 956 was 956, checked in by fielding@…, 9 years ago
forgot to set eol-style
Property svn:eol-style set to `native`
File size: 98.1 KB

Rev	Line
[955]	1
	2
	3
	4	HTTPbis Working Group R. Fielding, Ed.
	5	Internet-Draft Day Software
	6	Obsoletes: 2616 (if approved) J. Gettys
	7	Intended status: Standards Track Alcatel-Lucent
	8	Expires: January 13, 2011 J. Mogul
	9	HP
	10	H. Frystyk
	11	Microsoft
	12	L. Masinter
	13	Adobe Systems
	14	P. Leach
	15	Microsoft
	16	T. Berners-Lee
	17	W3C/MIT
	18	Y. Lafon, Ed.
	19	W3C
	20	J. Reschke, Ed.
	21	greenbytes
	22	July 12, 2010
	23
	24
	25	HTTP/1.1, part 3: Message Payload and Content Negotiation
	26	draft-ietf-httpbis-p3-payload-10
	27
	28	Abstract
	29
	30	The Hypertext Transfer Protocol (HTTP) is an application-level
	31	protocol for distributed, collaborative, hypermedia information
	32	systems. HTTP has been in use by the World Wide Web global
	33	information initiative since 1990. This document is Part 3 of the
	34	seven-part specification that defines the protocol referred to as
	35	"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines
	36	HTTP message content, metadata, and content negotiation.
	37
	38	Editorial Note (To be removed by RFC Editor)
	39
	40	Discussion of this draft should take place on the HTTPBIS working
	41	group mailing list (ietf-http-wg@w3.org). The current issues list is
	42	at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	43	documents (including fancy diffs) can be found at
	44	<http://tools.ietf.org/wg/httpbis/>.
	45
	46	The changes in this draft are summarized in Appendix E.11.
	47
	48	Status of This Memo
	49
	50	This Internet-Draft is submitted in full conformance with the
	51	provisions of BCP 78 and BCP 79.
	52
	53
	54
	55	Fielding, et al. Expires January 13, 2011 [Page 1]
	56
	57	Internet-Draft HTTP/1.1, Part 3 July 2010
	58
	59
	60	Internet-Drafts are working documents of the Internet Engineering
	61	Task Force (IETF). Note that other groups may also distribute
	62	working documents as Internet-Drafts. The list of current Internet-
	63	Drafts is at http://datatracker.ietf.org/drafts/current/.
	64
	65	Internet-Drafts are draft documents valid for a maximum of six months
	66	and may be updated, replaced, or obsoleted by other documents at any
	67	time. It is inappropriate to use Internet-Drafts as reference
	68	material or to cite them other than as "work in progress."
	69
	70	This Internet-Draft will expire on January 13, 2011.
	71
	72	Copyright Notice
	73
	74	Copyright (c) 2010 IETF Trust and the persons identified as the
	75	document authors. All rights reserved.
	76
	77	This document is subject to BCP 78 and the IETF Trust's Legal
	78	Provisions Relating to IETF Documents
	79	(http://trustee.ietf.org/license-info) in effect on the date of
	80	publication of this document. Please review these documents
	81	carefully, as they describe your rights and restrictions with respect
	82	to this document. Code Components extracted from this document must
	83	include Simplified BSD License text as described in Section 4.e of
	84	the Trust Legal Provisions and are provided without warranty as
	85	described in the Simplified BSD License.
	86
	87	This document may contain material from IETF Documents or IETF
	88	Contributions published or made publicly available before November
	89	10, 2008. The person(s) controlling the copyright in some of this
	90	material may not have granted the IETF Trust the right to allow
	91	modifications of such material outside the IETF Standards Process.
	92	Without obtaining an adequate license from the person(s) controlling
	93	the copyright in such materials, this document may not be modified
	94	outside the IETF Standards Process, and derivative works of it may
	95	not be created outside the IETF Standards Process, except to format
	96	it for publication as an RFC or to translate it into languages other
	97	than English.
	98
	99	Table of Contents
	100
	101	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	102	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	103	1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
	104	1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
	105	1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6
	106	1.3.2. ABNF Rules defined in other Parts of the
	107	Specification . . . . . . . . . . . . . . . . . . . . 6
	108
	109
	110
	111	Fielding, et al. Expires January 13, 2011 [Page 2]
	112
	113	Internet-Draft HTTP/1.1, Part 3 July 2010
	114
	115
	116	2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 7
	117	2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 7
	118	2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 8
	119	2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 8
	120	2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 9
	121	2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9
	122	2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 10
	123	2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 11
	124	2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 12
	125	3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	126	3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 12
	127	3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 13
	128	3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 13
	129	3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 14
	130	4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14
	131	4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 15
	132	4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16
	133	5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17
	134	5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	135	5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19
	136	5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 20
	137	5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21
	138	5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22
	139	5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23
	140	5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24
	141	5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25
	142	5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26
	143	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
	144	6.1. Message Header Registration . . . . . . . . . . . . . . . 26
	145	6.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27
	146	7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
	147	7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 28
	148	7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 28
	149	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
	150	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	151	9.1. Normative References . . . . . . . . . . . . . . . . . . . 29
	152	9.2. Informative References . . . . . . . . . . . . . . . . . . 31
	153	Appendix A. Differences Between HTTP Entities and RFC 2045
	154	Entities . . . . . . . . . . . . . . . . . . . . . . 32
	155	A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 32
	156	A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33
	157	A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 33
	158	A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 33
	159	A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 34
	160	A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 34
	161	A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 34
	162	Appendix B. Additional Features . . . . . . . . . . . . . . . . . 34
	163	B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 35
	164
	165
	166
	167	Fielding, et al. Expires January 13, 2011 [Page 3]
	168
	169	Internet-Draft HTTP/1.1, Part 3 July 2010
	170
	171
	172	Appendix C. Compatibility with Previous Versions . . . . . . . . 35
	173	C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 35
	174	C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 36
	175	Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 36
	176	Appendix E. Change Log (to be removed by RFC Editor before
	177	publication) . . . . . . . . . . . . . . . . . . . . 38
	178	E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 38
	179	E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 38
	180	E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 39
	181	E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 39
	182	E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 40
	183	E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 40
	184	E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 41
	185	E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 41
	186	E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 41
	187	E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 42
	188	E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 42
	189	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
	190
	191
	192
	193
	194
	195
	196
	197
	198
	199
	200
	201
	202
	203
	204
	205
	206
	207
	208
	209
	210
	211
	212
	213
	214
	215
	216
	217
	218
	219
	220
	221
	222
	223	Fielding, et al. Expires January 13, 2011 [Page 4]
	224
	225	Internet-Draft HTTP/1.1, Part 3 July 2010
	226
	227
	228	1. Introduction
	229
	230	This document defines HTTP/1.1 message payloads (a.k.a., content),
	231	the associated metadata header fields that define how the payload is
	232	intended to be interpreted by a recipient, the request header fields
	233	that may influence content selection, and the various selection
	234	algorithms that are collectively referred to as HTTP content
	235	negotiation.
	236
	237	This document is currently disorganized in order to minimize the
	238	changes between drafts and enable reviewers to see the smaller errata
	239	changes. The next draft will reorganize the sections to better
	240	reflect the content. In particular, the sections on entities will be
	241	renamed payload and moved to the first half of the document, while
	242	the sections on content negotiation and associated request header
	243	fields will be moved to the second half. The current mess reflects
	244	how widely dispersed these topics and associated requirements had
	245	become in [RFC2616].
	246
	247	1.1. Terminology
	248
	249	This specification uses a number of terms to refer to the roles
	250	played by participants in, and objects of, the HTTP communication.
	251
	252	content negotiation
	253
	254	The mechanism for selecting the appropriate representation when
	255	servicing a request. The representation of entities in any
	256	response can be negotiated (including error responses).
	257
	258	entity
	259
	260	The information transferred as the payload of a request or
	261	response. An entity consists of metadata in the form of entity-
	262	header fields and content in the form of an entity-body.
	263
	264	representation
	265
	266	An entity included with a response that is subject to content
	267	negotiation. There may exist multiple representations associated
	268	with a particular response status.
	269
	270	variant
	271
	272	A resource may have one, or more than one, representation(s)
	273	associated with it at any given instant. Each of these
	274	representations is termed a "variant". Use of the term "variant"
	275	does not necessarily imply that the resource is subject to content
	276
	277
	278
	279	Fielding, et al. Expires January 13, 2011 [Page 5]
	280
	281	Internet-Draft HTTP/1.1, Part 3 July 2010
	282
	283
	284	negotiation.
	285
	286	1.2. Requirements
	287
	288	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	289	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	290	document are to be interpreted as described in [RFC2119].
	291
	292	An implementation is not compliant if it fails to satisfy one or more
	293	of the "MUST" or "REQUIRED" level requirements for the protocols it
	294	implements. An implementation that satisfies all the "MUST" or
	295	"REQUIRED" level and all the "SHOULD" level requirements for its
	296	protocols is said to be "unconditionally compliant"; one that
	297	satisfies all the "MUST" level requirements but not all the "SHOULD"
	298	level requirements for its protocols is said to be "conditionally
	299	compliant".
	300
	301	1.3. Syntax Notation
	302
	303	This specification uses the ABNF syntax defined in Section 1.2 of
	304	[Part1] (which extends the syntax defined in [RFC5234] with a list
	305	rule). Appendix D shows the collected ABNF, with the list rule
	306	expanded.
	307
	308	The following core rules are included by reference, as defined in
	309	[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
	310	(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
	311	HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
	312	sequence of data), SP (space), VCHAR (any visible USASCII character),
	313	and WSP (whitespace).
	314
	315	1.3.1. Core Rules
	316
	317	The core rules below are defined in Section 1.2.2 of [Part1]:
	318
	319	quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
	320	token = <token, defined in [Part1], Section 1.2.2>
	321	word = <word, defined in [Part1], Section 1.2.2>
	322	OWS = <OWS, defined in [Part1], Section 1.2.2>
	323
	324	1.3.2. ABNF Rules defined in other Parts of the Specification
	325
	326	The ABNF rules below are defined in other parts:
	327
	328	absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
	329	Content-Length = <Content-Length, defined in [Part1], Section 9.2>
	330	header-field = <header-field, defined in [Part1], Section 3.2>
	331	partial-URI = <partial-URI, defined in [Part1], Section 2.6>
	332
	333
	334
	335	Fielding, et al. Expires January 13, 2011 [Page 6]
	336
	337	Internet-Draft HTTP/1.1, Part 3 July 2010
	338
	339
	340	qvalue = <qvalue, defined in [Part1], Section 6.4>
	341
	342
	343	Last-Modified = <Last-Modified, defined in [Part4], Section 6.6>
	344
	345
	346	Content-Range = <Content-Range, defined in [Part5], Section 5.2>
	347
	348
	349	Expires = <Expires, defined in [Part6], Section 3.3>
	350
	351	2. Protocol Parameters
	352
	353	2.1. Character Sets
	354
	355	HTTP uses the same definition of the term "character set" as that
	356	described for MIME:
	357
	358	The term "character set" is used in this document to refer to a
	359	method used with one or more tables to convert a sequence of octets
	360	into a sequence of characters. Note that unconditional conversion in
	361	the other direction is not required, in that not all characters may
	362	be available in a given character set and a character set may provide
	363	more than one sequence of octets to represent a particular character.
	364	This definition is intended to allow various kinds of character
	365	encoding, from simple single-table mappings such as US-ASCII to
	366	complex table switching methods such as those that use ISO-2022's
	367	techniques. However, the definition associated with a MIME character
	368	set name MUST fully specify the mapping to be performed from octets
	369	to characters. In particular, use of external profiling information
	370	to determine the exact mapping is not permitted.
	371
	372	Note: This use of the term "character set" is more commonly
	373	referred to as a "character encoding." However, since HTTP and
	374	MIME share the same registry, it is important that the terminology
	375	also be shared.
	376
	377	HTTP character sets are identified by case-insensitive tokens. The
	378	complete set of tokens is defined by the IANA Character Set registry
	379	(<http://www.iana.org/assignments/character-sets>).
	380
	381	charset = token
	382
	383	Although HTTP allows an arbitrary token to be used as a charset
	384	value, any token that has a predefined value within the IANA
	385	Character Set registry MUST represent the character set defined by
	386	that registry. Applications SHOULD limit their use of character sets
	387	to those defined by the IANA registry.
	388
	389
	390
	391	Fielding, et al. Expires January 13, 2011 [Page 7]
	392
	393	Internet-Draft HTTP/1.1, Part 3 July 2010
	394
	395
	396	HTTP uses charset in two contexts: within an Accept-Charset request
	397	header (in which the charset value is an unquoted token) and as the
	398	value of a parameter in a Content-Type header (within a request or
	399	response), in which case the parameter value of the charset parameter
	400	may be quoted.
	401
	402	Implementors should be aware of IETF character set requirements
	403	[RFC3629] [RFC2277].
	404
	405	2.1.1. Missing Charset
	406
	407	Some HTTP/1.0 software has interpreted a Content-Type header without
	408	charset parameter incorrectly to mean "recipient should guess."
	409	Senders wishing to defeat this behavior MAY include a charset
	410	parameter even when the charset is ISO-8859-1 ([ISO-8859-1]) and
	411	SHOULD do so when it is known that it will not confuse the recipient.
	412
	413	Unfortunately, some older HTTP/1.0 clients did not deal properly with
	414	an explicit charset parameter. HTTP/1.1 recipients MUST respect the
	415	charset label provided by the sender; and those user agents that have
	416	a provision to "guess" a charset MUST use the charset from the
	417	content-type field if they support that charset, rather than the
	418	recipient's preference, when initially displaying a document. See
	419	Section 2.3.1.
	420
	421	2.2. Content Codings
	422
	423	Content coding values indicate an encoding transformation that has
	424	been or can be applied to an entity. Content codings are primarily
	425	used to allow a document to be compressed or otherwise usefully
	426	transformed without losing the identity of its underlying media type
	427	and without loss of information. Frequently, the entity is stored in
	428	coded form, transmitted directly, and only decoded by the recipient.
	429
	430	content-coding = token
	431
	432	All content-coding values are case-insensitive. HTTP/1.1 uses
	433	content-coding values in the Accept-Encoding (Section 5.3) and
	434	Content-Encoding (Section 5.5) header fields. Although the value
	435	describes the content-coding, what is more important is that it
	436	indicates what decoding mechanism will be required to remove the
	437	encoding.
	438
	439	compress
	440
	441	See Section 6.2.2.1 of [Part1].
	442
	443	deflate
	444
	445
	446
	447	Fielding, et al. Expires January 13, 2011 [Page 8]
	448
	449	Internet-Draft HTTP/1.1, Part 3 July 2010
	450
	451
	452	See Section 6.2.2.2 of [Part1].
	453
	454	gzip
	455
	456	See Section 6.2.2.3 of [Part1].
	457
	458	identity
	459
	460	The default (identity) encoding; the use of no transformation
	461	whatsoever. This content-coding is used only in the Accept-
	462	Encoding header, and SHOULD NOT be used in the Content-Encoding
	463	header.
	464
	465	2.2.1. Content Coding Registry
	466
	467	The HTTP Content Coding Registry defines the name space for the
	468	content coding names.
	469
	470	Registrations MUST include the following fields:
	471
	472	o Name
	473
	474	o Description
	475
	476	o Pointer to specification text
	477
	478	Names of content codings MUST NOT overlap with names of transfer
	479	codings (Section 6.2 of [Part1]), unless the encoding transformation
	480	is identical (as it is the case for the compression codings defined
	481	in Section 6.2.2 of [Part1]).
	482
	483	Values to be added to this name space require expert review and a
	484	specification (see "Expert Review" and "Specification Required" in
	485	Section 4.1 of [RFC5226]), and MUST conform to the purpose of content
	486	coding defined in this section.
	487
	488	The registry itself is maintained at
	489	<http://www.iana.org/assignments/http-parameters>.
	490
	491	2.3. Media Types
	492
	493	HTTP uses Internet Media Types [RFC2046] in the Content-Type
	494	(Section 5.9) and Accept (Section 5.1) header fields in order to
	495	provide open and extensible data typing and type negotiation.
	496
	497	media-type = type "/" subtype *( OWS ";" OWS parameter )
	498	type = token
	499	subtype = token
	500
	501
	502
	503	Fielding, et al. Expires January 13, 2011 [Page 9]
	504
	505	Internet-Draft HTTP/1.1, Part 3 July 2010
	506
	507
	508	Parameters MAY follow the type/subtype in the form of attribute/value
	509	pairs.
	510
	511	parameter = attribute "=" value
	512	attribute = token
	513	value = word
	514
	515	The type, subtype, and parameter attribute names are case-
	516	insensitive. Parameter values might or might not be case-sensitive,
	517	depending on the semantics of the parameter name. The presence or
	518	absence of a parameter might be significant to the processing of a
	519	media-type, depending on its definition within the media type
	520	registry.
	521
	522	A parameter value that matches the token production may be
	523	transmitted as either a token or within a quoted-string. The quoted
	524	and unquoted values are equivalent.
	525
	526	Note that some older HTTP applications do not recognize media type
	527	parameters. When sending data to older HTTP applications,
	528	implementations SHOULD only use media type parameters when they are
	529	required by that type/subtype definition.
	530
	531	Media-type values are registered with the Internet Assigned Number
	532	Authority (IANA). The media type registration process is outlined in
	533	[RFC4288]. Use of non-registered media types is discouraged.
	534
	535	2.3.1. Canonicalization and Text Defaults
	536
	537	Internet media types are registered with a canonical form. An
	538	entity-body transferred via HTTP messages MUST be represented in the
	539	appropriate canonical form prior to its transmission except for
	540	"text" types, as defined in the next paragraph.
	541
	542	When in canonical form, media subtypes of the "text" type use CRLF as
	543	the text line break. HTTP relaxes this requirement and allows the
	544	transport of text media with plain CR or LF alone representing a line
	545	break when it is done consistently for an entire entity-body. HTTP
	546	applications MUST accept CRLF, bare CR, and bare LF as being
	547	representative of a line break in text media received via HTTP. In
	548	addition, if the text is represented in a character set that does not
	549	use octets 13 and 10 for CR and LF respectively, as is the case for
	550	some multi-byte character sets, HTTP allows the use of whatever octet
	551	sequences are defined by that character set to represent the
	552	equivalent of CR and LF for line breaks. This flexibility regarding
	553	line breaks applies only to text media in the entity-body; a bare CR
	554	or LF MUST NOT be substituted for CRLF within any of the HTTP control
	555	structures (such as header fields and multipart boundaries).
	556
	557
	558
	559	Fielding, et al. Expires January 13, 2011 [Page 10]
	560
	561	Internet-Draft HTTP/1.1, Part 3 July 2010
	562
	563
	564	If an entity-body is encoded with a content-coding, the underlying
	565	data MUST be in a form defined above prior to being encoded.
	566
	567	The "charset" parameter is used with some media types to define the
	568	character set (Section 2.1) of the data. When no explicit charset
	569	parameter is provided by the sender, media subtypes of the "text"
	570	type are defined to have a default charset value of "ISO-8859-1" when
	571	received via HTTP. Data in character sets other than "ISO-8859-1" or
	572	its subsets MUST be labeled with an appropriate charset value. See
	573	Section 2.1.1 for compatibility problems.
	574
	575	2.3.2. Multipart Types
	576
	577	MIME provides for a number of "multipart" types -- encapsulations of
	578	one or more entities within a single message-body. All multipart
	579	types share a common syntax, as defined in Section 5.1.1 of
	580	[RFC2046], and MUST include a boundary parameter as part of the media
	581	type value. The message body is itself a protocol element and MUST
	582	therefore use only CRLF to represent line breaks between body-parts.
	583	Unlike in RFC 2046, the epilogue of any multipart message MUST be
	584	empty; HTTP applications MUST NOT transmit the epilogue (even if the
	585	original multipart contains an epilogue). These restrictions exist
	586	in order to preserve the self-delimiting nature of a multipart
	587	message-body, wherein the "end" of the message-body is indicated by
	588	the ending multipart boundary.
	589
	590	In general, HTTP treats a multipart message-body no differently than
	591	any other media type: strictly as payload. The one exception is the
	592	"multipart/byteranges" type (Appendix A of [Part5]) when it appears
	593	in a 206 (Partial Content) response. In all other cases, an HTTP
	594	user agent SHOULD follow the same or similar behavior as a MIME user
	595	agent would upon receipt of a multipart type. The MIME header fields
	596	within each body-part of a multipart message-body do not have any
	597	significance to HTTP beyond that defined by their MIME semantics.
	598
	599	In general, an HTTP user agent SHOULD follow the same or similar
	600	behavior as a MIME user agent would upon receipt of a multipart type.
	601	If an application receives an unrecognized multipart subtype, the
	602	application MUST treat it as being equivalent to "multipart/mixed".
	603
	604	Note: The "multipart/form-data" type has been specifically defined
	605	for carrying form data suitable for processing via the POST
	606	request method, as described in [RFC2388].
	607
	608
	609
	610
	611
	612
	613
	614
	615	Fielding, et al. Expires January 13, 2011 [Page 11]
	616
	617	Internet-Draft HTTP/1.1, Part 3 July 2010
	618
	619
	620	2.4. Language Tags
	621
	622	A language tag, as defined in [RFC5646], identifies a natural
	623	language spoken, written, or otherwise conveyed by human beings for
	624	communication of information to other human beings. Computer
	625	languages are explicitly excluded. HTTP uses language tags within
	626	the Accept-Language and Content-Language fields.
	627
	628	In summary, a language tag is composed of one or more parts: A
	629	primary language subtag followed by a possibly empty series of
	630	subtags:
	631
	632	language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>
	633
	634	White space is not allowed within the tag and all tags are case-
	635	insensitive. The name space of language subtags is administered by
	636	the IANA (see
	637	<http://www.iana.org/assignments/language-subtag-registry>).
	638
	639	Example tags include:
	640
	641	en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
	642
	643	See [RFC5646] for further information.
	644
	645	3. Entity
	646
	647	Request and Response messages MAY transfer an entity if not otherwise
	648	restricted by the request method or response status code. An entity
	649	consists of entity-header fields and an entity-body, although some
	650	responses will only include the entity-headers.
	651
	652	In this section, both sender and recipient refer to either the client
	653	or the server, depending on who sends and who receives the entity.
	654
	655	3.1. Entity Header Fields
	656
	657	Entity-header fields define metainformation about the entity-body or,
	658	if no body is present, about the resource identified by the request.
	659
	660
	661
	662
	663
	664
	665
	666
	667
	668
	669
	670
	671	Fielding, et al. Expires January 13, 2011 [Page 12]
	672
	673	Internet-Draft HTTP/1.1, Part 3 July 2010
	674
	675
	676	entity-header = Content-Encoding ; Section 5.5
	677	/ Content-Language ; Section 5.6
	678	/ Content-Length ; [Part1], Section 9.2
	679	/ Content-Location ; Section 5.7
	680	/ Content-MD5 ; Section 5.8
	681	/ Content-Range ; [Part5], Section 5.2
	682	/ Content-Type ; Section 5.9
	683	/ Expires ; [Part6], Section 3.3
	684	/ Last-Modified ; [Part4], Section 6.6
	685	/ extension-header
	686
	687	extension-header = header-field
	688
	689	The extension-header mechanism allows additional entity-header fields
	690	to be defined without changing the protocol, but these fields cannot
	691	be assumed to be recognizable by the recipient. Unrecognized header
	692	fields SHOULD be ignored by the recipient and MUST be forwarded by
	693	transparent proxies.
	694
	695	3.2. Entity Body
	696
	697	The entity-body (if any) sent with an HTTP request or response is in
	698	a format and encoding defined by the entity-header fields.
	699
	700	entity-body = *OCTET
	701
	702	An entity-body is only present in a message when a message-body is
	703	present, as described in Section 3.3 of [Part1]. The entity-body is
	704	obtained from the message-body by decoding any Transfer-Encoding that
	705	might have been applied to ensure safe and proper transfer of the
	706	message.
	707
	708	3.2.1. Type
	709
	710	When an entity-body is included with a message, the data type of that
	711	body is determined via the header fields Content-Type and Content-
	712	Encoding. These define a two-layer, ordered encoding model:
	713
	714	entity-body := Content-Encoding( Content-Type( data ) )
	715
	716	Content-Type specifies the media type of the underlying data. Any
	717	HTTP/1.1 message containing an entity-body SHOULD include a Content-
	718	Type header field defining the media type of that body, unless that
	719	information is unknown.
	720
	721	If the Content-Type header field is not present, it indicates that
	722	the sender does not know the media type of the data; recipients MAY
	723	either assume that it is "application/octet-stream" ([RFC2046],
	724
	725
	726
	727	Fielding, et al. Expires January 13, 2011 [Page 13]
	728
	729	Internet-Draft HTTP/1.1, Part 3 July 2010
	730
	731
	732	Section 4.5.1) or examine the content to determine its type.
	733
	734	In practice, currently-deployed servers sometimes provide a Content-
	735	Type header which does not correctly convey the intended
	736	interpretation of the content sent, with the result that some clients
	737	will examine the response body's content and override the specified
	738	type.
	739
	740	Client that do so risk drawing incorrect conclusions, which may
	741	expose additional security risks (e.g., "privilege escalation").
	742	Implementers are encouraged to provide a means of disabling such
	743	"content sniffing" when it is used.
	744
	745	Content-Encoding may be used to indicate any additional content
	746	codings applied to the data, usually for the purpose of data
	747	compression, that are a property of the requested resource. There is
	748	no default encoding.
	749
	750	3.2.2. Entity Length
	751
	752	The entity-length of a message is the length of the message-body
	753	before any transfer-codings have been applied. Section 3.4 of
	754	[Part1] defines how the transfer-length of a message-body is
	755	determined.
	756
	757	4. Content Negotiation
	758
	759	HTTP responses include a representation which contains information
	760	for interpretation, whether by a human user or for further
	761	processing. Often, the server has different ways of representing the
	762	same information; for example, in different formats, languages, or
	763	using different character encodings.
	764
	765	HTTP clients and their users might have different or variable
	766	capabilities, characteristics or preferences which would influence
	767	which representation, among those available from the server, would be
	768	best for the server to deliver. For this reason, HTTP provides
	769	mechanisms for "content negotiation" -- a process of allowing
	770	selection of a representation of a given resource, when more than one
	771	is available.
	772
	773	This specification defines two patterns of content negotiation;
	774	"server-driven", where the server selects the representation based
	775	upon the client's stated preferences, and "agent-driven" negotiation,
	776	where the server provides a list of representations for the client to
	777	choose from, based upon their metadata. In addition, there are other
	778	patterns: some applications use an "active content" pattern, where
	779	the server returns active content which runs on the client and, based
	780
	781
	782
	783	Fielding, et al. Expires January 13, 2011 [Page 14]
	784
	785	Internet-Draft HTTP/1.1, Part 3 July 2010
	786
	787
	788	on client available parameters, selects additional resources to
	789	invoke. "Transparent Content Negotiation" ([RFC2295]) has also been
	790	proposed.
	791
	792	These patterns are all widely used, and have trade-offs in
	793	applicability and practicality. In particular, when the number of
	794	preferences or capabilities to be expressed by a client are large
	795	(such as when many different formats are supported by a user-agent),
	796	server-driven negotiation becomes unwieldy, and may not be
	797	appropriate. Conversely, when the number of representations to
	798	choose from is very large, agent-driven negotiation may not be
	799	appropriate.
	800
	801	Note that in all cases, the supplier of representations has the
	802	responsibility for determining which representations might be
	803	considered to be the "same information".
	804
	805	4.1. Server-driven Negotiation
	806
	807	If the selection of the best representation for a response is made by
	808	an algorithm located at the server, it is called server-driven
	809	negotiation. Selection is based on the available representations of
	810	the response (the dimensions over which it can vary; e.g., language,
	811	content-coding, etc.) and the contents of particular header fields in
	812	the request message or on other information pertaining to the request
	813	(such as the network address of the client).
	814
	815	Server-driven negotiation is advantageous when the algorithm for
	816	selecting from among the available representations is difficult to
	817	describe to the user agent, or when the server desires to send its
	818	"best guess" to the client along with the first response (hoping to
	819	avoid the round-trip delay of a subsequent request if the "best
	820	guess" is good enough for the user). In order to improve the
	821	server's guess, the user agent MAY include request header fields
	822	(Accept, Accept-Language, Accept-Encoding, etc.) which describe its
	823	preferences for such a response.
	824
	825	Server-driven negotiation has disadvantages:
	826
	827	1. It is impossible for the server to accurately determine what
	828	might be "best" for any given user, since that would require
	829	complete knowledge of both the capabilities of the user agent and
	830	the intended use for the response (e.g., does the user want to
	831	view it on screen or print it on paper?).
	832
	833	2. Having the user agent describe its capabilities in every request
	834	can be both very inefficient (given that only a small percentage
	835	of responses have multiple representations) and a potential
	836
	837
	838
	839	Fielding, et al. Expires January 13, 2011 [Page 15]
	840
	841	Internet-Draft HTTP/1.1, Part 3 July 2010
	842
	843
	844	violation of the user's privacy.
	845
	846	3. It complicates the implementation of an origin server and the
	847	algorithms for generating responses to a request.
	848
	849	4. It may limit a public cache's ability to use the same response
	850	for multiple user's requests.
	851
	852	HTTP/1.1 includes the following request-header fields for enabling
	853	server-driven negotiation through description of user agent
	854	capabilities and user preferences: Accept (Section 5.1), Accept-
	855	Charset (Section 5.2), Accept-Encoding (Section 5.3), Accept-Language
	856	(Section 5.4), and User-Agent (Section 9.9 of [Part2]). However, an
	857	origin server is not limited to these dimensions and MAY vary the
	858	response based on any aspect of the request, including information
	859	outside the request-header fields or within extension header fields
	860	not defined by this specification.
	861
	862	Note: In practice, User-Agent based negotiation is fragile,
	863	because new clients might not be recognized.
	864
	865	The Vary header field (Section 3.5 of [Part6]) can be used to express
	866	the parameters the server uses to select a representation that is
	867	subject to server-driven negotiation.
	868
	869	4.2. Agent-driven Negotiation
	870
	871	With agent-driven negotiation, selection of the best representation
	872	for a response is performed by the user agent after receiving an
	873	initial response from the origin server. Selection is based on a
	874	list of the available representations of the response included within
	875	the header fields or entity-body of the initial response, with each
	876	representation identified by its own URI. Selection from among the
	877	representations may be performed automatically (if the user agent is
	878	capable of doing so) or manually by the user selecting from a
	879	generated (possibly hypertext) menu.
	880
	881	Agent-driven negotiation is advantageous when the response would vary
	882	over commonly-used dimensions (such as type, language, or encoding),
	883	when the origin server is unable to determine a user agent's
	884	capabilities from examining the request, and generally when public
	885	caches are used to distribute server load and reduce network usage.
	886
	887	Agent-driven negotiation suffers from the disadvantage of needing a
	888	second request to obtain the best alternate representation. This
	889	second request is only efficient when caching is used. In addition,
	890	this specification does not define any mechanism for supporting
	891	automatic selection, though it also does not prevent any such
	892
	893
	894
	895	Fielding, et al. Expires January 13, 2011 [Page 16]
	896
	897	Internet-Draft HTTP/1.1, Part 3 July 2010
	898
	899
	900	mechanism from being developed as an extension and used within
	901	HTTP/1.1.
	902
	903	This specification defines the 300 (Multiple Choices) and 406 (Not
	904	Acceptable) status codes for enabling agent-driven negotiation when
	905	the server is unwilling or unable to provide a varying response using
	906	server-driven negotiation.
	907
	908	5. Header Field Definitions
	909
	910	This section defines the syntax and semantics of HTTP/1.1 header
	911	fields related to the payload of messages.
	912
	913	For entity-header fields, both sender and recipient refer to either
	914	the client or the server, depending on who sends and who receives the
	915	entity.
	916
	917	5.1. Accept
	918
	919	The "Accept" request-header field can be used by user agents to
	920	specify response media types that are acceptable. Accept headers can
	921	be used to indicate that the request is specifically limited to a
	922	small set of desired types, as in the case of a request for an in-
	923	line image.
	924
	925	Accept = "Accept" ":" OWS Accept-v
	926	Accept-v = #( media-range [ accept-params ] )
	927
	928	media-range = ( "/"
	929	/ ( type "/" "*" )
	930	/ ( type "/" subtype )
	931	) *( OWS ";" OWS parameter )
	932	accept-params = OWS ";" OWS "q=" qvalue *( accept-ext )
	933	accept-ext = OWS ";" OWS token
	934	[ "=" word ]
	935
	936	The asterisk "*" character is used to group media types into ranges,
	937	with "/" indicating all media types and "type/*" indicating all
	938	subtypes of that type. The media-range MAY include media type
	939	parameters that are applicable to that range.
	940
	941	Each media-range MAY be followed by one or more accept-params,
	942	beginning with the "q" parameter for indicating a relative quality
	943	factor. The first "q" parameter (if any) separates the media-range
	944	parameter(s) from the accept-params. Quality factors allow the user
	945	or user agent to indicate the relative degree of preference for that
	946	media-range, using the qvalue scale from 0 to 1 (Section 6.4 of
	947	[Part1]). The default value is q=1.
	948
	949
	950
	951	Fielding, et al. Expires January 13, 2011 [Page 17]
	952
	953	Internet-Draft HTTP/1.1, Part 3 July 2010
	954
	955
	956	Note: Use of the "q" parameter name to separate media type
	957	parameters from Accept extension parameters is due to historical
	958	practice. Although this prevents any media type parameter named
	959	"q" from being used with a media range, such an event is believed
	960	to be unlikely given the lack of any "q" parameters in the IANA
	961	media type registry and the rare usage of any media type
	962	parameters in Accept. Future media types are discouraged from
	963	registering any parameter named "q".
	964
	965	The example
	966
	967	Accept: audio/*; q=0.2, audio/basic
	968
	969	SHOULD be interpreted as "I prefer audio/basic, but send me any audio
	970	type if it is the best available after an 80% mark-down in quality."
	971
	972	If no Accept header field is present, then it is assumed that the
	973	client accepts all media types. If an Accept header field is
	974	present, and if the server cannot send a response which is acceptable
	975	according to the combined Accept field value, then the server SHOULD
	976	send a 406 (Not Acceptable) response.
	977
	978	A more elaborate example is
	979
	980	Accept: text/plain; q=0.5, text/html,
	981	text/x-dvi; q=0.8, text/x-c
	982
	983	Verbally, this would be interpreted as "text/html and text/x-c are
	984	the preferred media types, but if they do not exist, then send the
	985	text/x-dvi entity, and if that does not exist, send the text/plain
	986	entity."
	987
	988	Media ranges can be overridden by more specific media ranges or
	989	specific media types. If more than one media range applies to a
	990	given type, the most specific reference has precedence. For example,
	991
	992	Accept: text/, text/html, text/html;level=1, /*
	993
	994	have the following precedence:
	995
	996	1. text/html;level=1
	997
	998	2. text/html
	999
	1000	3. text/*
	1001
	1002	4. /
	1003
	1004
	1005
	1006
	1007	Fielding, et al. Expires January 13, 2011 [Page 18]
	1008
	1009	Internet-Draft HTTP/1.1, Part 3 July 2010
	1010
	1011
	1012	The media type quality factor associated with a given type is
	1013	determined by finding the media range with the highest precedence
	1014	which matches that type. For example,
	1015
	1016	Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
	1017	text/html;level=2;q=0.4, /;q=0.5
	1018
	1019	would cause the following values to be associated:
	1020
	1021	+-------------------+---------------+
	1022	\| Media Type \| Quality Value \|
	1023	+-------------------+---------------+
	1024	\| text/html;level=1 \| 1 \|
	1025	\| text/html \| 0.7 \|
	1026	\| text/plain \| 0.3 \|
	1027	\| image/jpeg \| 0.5 \|
	1028	\| text/html;level=2 \| 0.4 \|
	1029	\| text/html;level=3 \| 0.7 \|
	1030	+-------------------+---------------+
	1031
	1032	Note: A user agent might be provided with a default set of quality
	1033	values for certain media ranges. However, unless the user agent is a
	1034	closed system which cannot interact with other rendering agents, this
	1035	default set ought to be configurable by the user.
	1036
	1037	5.2. Accept-Charset
	1038
	1039	The "Accept-Charset" request-header field can be used by user agents
	1040	to indicate what response character sets are acceptable. This field
	1041	allows clients capable of understanding more comprehensive or
	1042	special-purpose character sets to signal that capability to a server
	1043	which is capable of representing documents in those character sets.
	1044
	1045	Accept-Charset = "Accept-Charset" ":" OWS
	1046	Accept-Charset-v
	1047	Accept-Charset-v = 1#( ( charset / "*" )
	1048	[ OWS ";" OWS "q=" qvalue ] )
	1049
	1050	Character set values are described in Section 2.1. Each charset MAY
	1051	be given an associated quality value which represents the user's
	1052	preference for that charset. The default value is q=1. An example
	1053	is
	1054
	1055	Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
	1056
	1057	The special value "*", if present in the Accept-Charset field,
	1058	matches every character set (including ISO-8859-1) which is not
	1059	mentioned elsewhere in the Accept-Charset field. If no "*" is
	1060
	1061
	1062
	1063	Fielding, et al. Expires January 13, 2011 [Page 19]
	1064
	1065	Internet-Draft HTTP/1.1, Part 3 July 2010
	1066
	1067
	1068	present in an Accept-Charset field, then all character sets not
	1069	explicitly mentioned get a quality value of 0, except for ISO-8859-1,
	1070	which gets a quality value of 1 if not explicitly mentioned.
	1071
	1072	If no Accept-Charset header is present, the default is that any
	1073	character set is acceptable. If an Accept-Charset header is present,
	1074	and if the server cannot send a response which is acceptable
	1075	according to the Accept-Charset header, then the server SHOULD send
	1076	an error response with the 406 (Not Acceptable) status code, though
	1077	the sending of an unacceptable response is also allowed.
	1078
	1079	5.3. Accept-Encoding
	1080
	1081	The "Accept-Encoding" request-header field can be used by user agents
	1082	to indicate what response content-codings (Section 2.2) are
	1083	acceptable in the response.
	1084
	1085	Accept-Encoding = "Accept-Encoding" ":" OWS
	1086	Accept-Encoding-v
	1087	Accept-Encoding-v =
	1088	#( codings [ OWS ";" OWS "q=" qvalue ] )
	1089	codings = ( content-coding / "*" )
	1090
	1091	Each codings value MAY be given an associated quality value which
	1092	represents the preference for that encoding. The default value is
	1093	q=1.
	1094
	1095	Examples of its use are:
	1096
	1097	Accept-Encoding: compress, gzip
	1098	Accept-Encoding:
	1099	Accept-Encoding: *
	1100	Accept-Encoding: compress;q=0.5, gzip;q=1.0
	1101	Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
	1102
	1103	A server tests whether a content-coding is acceptable, according to
	1104	an Accept-Encoding field, using these rules:
	1105
	1106	1. If the content-coding is one of the content-codings listed in the
	1107	Accept-Encoding field, then it is acceptable, unless it is
	1108	accompanied by a qvalue of 0. (As defined in Section 6.4 of
	1109	[Part1], a qvalue of 0 means "not acceptable.")
	1110
	1111	2. The special "*" symbol in an Accept-Encoding field matches any
	1112	available content-coding not explicitly listed in the header
	1113	field.
	1114
	1115
	1116
	1117
	1118
	1119	Fielding, et al. Expires January 13, 2011 [Page 20]
	1120
	1121	Internet-Draft HTTP/1.1, Part 3 July 2010
	1122
	1123
	1124	3. If multiple content-codings are acceptable, then the acceptable
	1125	content-coding with the highest non-zero qvalue is preferred.
	1126
	1127	4. The "identity" content-coding is always acceptable, unless
	1128	specifically refused because the Accept-Encoding field includes
	1129	"identity;q=0", or because the field includes "*;q=0" and does
	1130	not explicitly include the "identity" content-coding. If the
	1131	Accept-Encoding field-value is empty, then only the "identity"
	1132	encoding is acceptable.
	1133
	1134	If an Accept-Encoding field is present in a request, and if the
	1135	server cannot send a response which is acceptable according to the
	1136	Accept-Encoding header, then the server SHOULD send an error response
	1137	with the 406 (Not Acceptable) status code.
	1138
	1139	If no Accept-Encoding field is present in a request, the server MAY
	1140	assume that the client will accept any content coding. In this case,
	1141	if "identity" is one of the available content-codings, then the
	1142	server SHOULD use the "identity" content-coding, unless it has
	1143	additional information that a different content-coding is meaningful
	1144	to the client.
	1145
	1146	Note: If the request does not include an Accept-Encoding field,
	1147	and if the "identity" content-coding is unavailable, then content-
	1148	codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and
	1149	"compress") are preferred; some older clients improperly display
	1150	messages sent with other content-codings. The server might also
	1151	make this decision based on information about the particular user-
	1152	agent or client.
	1153
	1154	Note: Most HTTP/1.0 applications do not recognize or obey qvalues
	1155	associated with content-codings. This means that qvalues will not
	1156	work and are not permitted with x-gzip or x-compress.
	1157
	1158	5.4. Accept-Language
	1159
	1160	The "Accept-Language" request-header field can be used by user agents
	1161	to indicate the set of natural languages that are preferred in the
	1162	response. Language tags are defined in Section 2.4.
	1163
	1164	Accept-Language = "Accept-Language" ":" OWS
	1165	Accept-Language-v
	1166	Accept-Language-v =
	1167	1#( language-range [ OWS ";" OWS "q=" qvalue ] )
	1168	language-range =
	1169	<language-range, defined in [RFC4647], Section 2.1>
	1170
	1171	Each language-range can be given an associated quality value which
	1172
	1173
	1174
	1175	Fielding, et al. Expires January 13, 2011 [Page 21]
	1176
	1177	Internet-Draft HTTP/1.1, Part 3 July 2010
	1178
	1179
	1180	represents an estimate of the user's preference for the languages
	1181	specified by that range. The quality value defaults to "q=1". For
	1182	example,
	1183
	1184	Accept-Language: da, en-gb;q=0.8, en;q=0.7
	1185
	1186	would mean: "I prefer Danish, but will accept British English and
	1187	other types of English." (see also Section 2.3 of [RFC4647])
	1188
	1189	For matching, Section 3 of [RFC4647] defines several matching
	1190	schemes. Implementations can offer the most appropriate matching
	1191	scheme for their requirements.
	1192
	1193	Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is
	1194	identical to the matching scheme that was previously defined in
	1195	Section 14.4 of [RFC2616].
	1196
	1197	It might be contrary to the privacy expectations of the user to send
	1198	an Accept-Language header with the complete linguistic preferences of
	1199	the user in every request. For a discussion of this issue, see
	1200	Section 7.1.
	1201
	1202	As intelligibility is highly dependent on the individual user, it is
	1203	recommended that client applications make the choice of linguistic
	1204	preference available to the user. If the choice is not made
	1205	available, then the Accept-Language header field MUST NOT be given in
	1206	the request.
	1207
	1208	Note: When making the choice of linguistic preference available to
	1209	the user, we remind implementors of the fact that users are not
	1210	familiar with the details of language matching as described above,
	1211	and should provide appropriate guidance. As an example, users
	1212	might assume that on selecting "en-gb", they will be served any
	1213	kind of English document if British English is not available. A
	1214	user agent might suggest in such a case to add "en" to get the
	1215	best matching behavior.
	1216
	1217	5.5. Content-Encoding
	1218
	1219	The "Content-Encoding" entity-header field indicates what content-
	1220	codings have been applied to the entity-body, and thus what decoding
	1221	mechanisms must be applied in order to obtain the media-type
	1222	referenced by the Content-Type header field. Content-Encoding is
	1223	primarily used to allow a document to be compressed without losing
	1224	the identity of its underlying media type.
	1225
	1226	Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v
	1227	Content-Encoding-v = 1#content-coding
	1228
	1229
	1230
	1231	Fielding, et al. Expires January 13, 2011 [Page 22]
	1232
	1233	Internet-Draft HTTP/1.1, Part 3 July 2010
	1234
	1235
	1236	Content codings are defined in Section 2.2. An example of its use is
	1237
	1238	Content-Encoding: gzip
	1239
	1240	The content-coding is a characteristic of the entity identified by
	1241	the Effective Request URI (Section 4.3 of [Part1]). Typically, the
	1242	entity-body is stored with this encoding and is only decoded before
	1243	rendering or analogous usage. However, a non-transparent proxy MAY
	1244	modify the content-coding if the new coding is known to be acceptable
	1245	to the recipient, unless the "no-transform" cache-control directive
	1246	is present in the message.
	1247
	1248	If the content-coding of an entity is not "identity", then the
	1249	response MUST include a Content-Encoding entity-header (Section 5.5)
	1250	that lists the non-identity content-coding(s) used.
	1251
	1252	If the content-coding of an entity in a request message is not
	1253	acceptable to the origin server, the server SHOULD respond with a
	1254	status code of 415 (Unsupported Media Type).
	1255
	1256	If multiple encodings have been applied to an entity, the content
	1257	codings MUST be listed in the order in which they were applied.
	1258	Additional information about the encoding parameters MAY be provided
	1259	by other entity-header fields not defined by this specification.
	1260
	1261	5.6. Content-Language
	1262
	1263	The "Content-Language" entity-header field describes the natural
	1264	language(s) of the intended audience for the entity. Note that this
	1265	might not be equivalent to all the languages used within the entity-
	1266	body.
	1267
	1268	Content-Language = "Content-Language" ":" OWS Content-Language-v
	1269	Content-Language-v = 1#language-tag
	1270
	1271	Language tags are defined in Section 2.4. The primary purpose of
	1272	Content-Language is to allow a user to identify and differentiate
	1273	entities according to the user's own preferred language. Thus, if
	1274	the body content is intended only for a Danish-literate audience, the
	1275	appropriate field is
	1276
	1277	Content-Language: da
	1278
	1279	If no Content-Language is specified, the default is that the content
	1280	is intended for all language audiences. This might mean that the
	1281	sender does not consider it to be specific to any natural language,
	1282	or that the sender does not know for which language it is intended.
	1283
	1284
	1285
	1286
	1287	Fielding, et al. Expires January 13, 2011 [Page 23]
	1288
	1289	Internet-Draft HTTP/1.1, Part 3 July 2010
	1290
	1291
	1292	Multiple languages MAY be listed for content that is intended for
	1293	multiple audiences. For example, a rendition of the "Treaty of
	1294	Waitangi," presented simultaneously in the original Maori and English
	1295	versions, would call for
	1296
	1297	Content-Language: mi, en
	1298
	1299	However, just because multiple languages are present within an entity
	1300	does not mean that it is intended for multiple linguistic audiences.
	1301	An example would be a beginner's language primer, such as "A First
	1302	Lesson in Latin," which is clearly intended to be used by an English-
	1303	literate audience. In this case, the Content-Language would properly
	1304	only include "en".
	1305
	1306	Content-Language MAY be applied to any media type -- it is not
	1307	limited to textual documents.
	1308
	1309	5.7. Content-Location
	1310
	1311	The "Content-Location" entity-header field is used to supply a URI
	1312	for the entity in the message when it is accessible from a location
	1313	separate from the requested resource's URI.
	1314
	1315	A server SHOULD provide a Content-Location for the variant
	1316	corresponding to the response entity, especially in the case where a
	1317	resource has multiple entities associated with it, and those entities
	1318	actually have separate locations by which they might be individually
	1319	accessed, the server SHOULD provide a Content-Location for the
	1320	particular variant which is returned.
	1321
	1322	Content-Location = "Content-Location" ":" OWS
	1323	Content-Location-v
	1324	Content-Location-v =
	1325	absolute-URI / partial-URI
	1326
	1327	The Content-Location value is not a replacement for the Effective
	1328	Request URI (Section 4.3 of [Part1]); it is only a statement of the
	1329	location of the resource corresponding to this particular entity at
	1330	the time of the request. Future requests MAY may be addressed to the
	1331	Content-Location URI if the desire is to identify the source of that
	1332	particular entity.
	1333
	1334	Section 6.1 of [Part2] describes how clients may process the Content-
	1335	Location header field.
	1336
	1337	A cache cannot assume that an entity with a Content-Location
	1338	different from the URI used to retrieve it can be used to respond to
	1339	later requests on that Content-Location URI. However, the Content-
	1340
	1341
	1342
	1343	Fielding, et al. Expires January 13, 2011 [Page 24]
	1344
	1345	Internet-Draft HTTP/1.1, Part 3 July 2010
	1346
	1347
	1348	Location can be used to differentiate between multiple entities
	1349	retrieved from a single requested resource, as described in Section
	1350	2.7 of [Part6].
	1351
	1352	If the Content-Location is a relative URI, the relative URI is
	1353	interpreted relative to the Effective Request URI.
	1354
	1355	The meaning of the Content-Location header in requests is undefined;
	1356	servers are free to ignore it in those cases.
	1357
	1358	5.8. Content-MD5
	1359
	1360	The "Content-MD5" entity-header field, as defined in [RFC1864], is an
	1361	MD5 digest of the entity-body that provides an end-to-end message
	1362	integrity check (MIC) of the entity-body. Note that a MIC is good
	1363	for detecting accidental modification of the entity-body in transit,
	1364	but is not proof against malicious attacks.
	1365
	1366	Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v
	1367	Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]>
	1368
	1369	The Content-MD5 header field MAY be generated by an origin server or
	1370	client to function as an integrity check of the entity-body. Only
	1371	origin servers or clients MAY generate the Content-MD5 header field;
	1372	proxies and gateways MUST NOT generate it, as this would defeat its
	1373	value as an end-to-end integrity check. Any recipient of the entity-
	1374	body, including gateways and proxies, MAY check that the digest value
	1375	in this header field matches that of the entity-body as received.
	1376
	1377	The MD5 digest is computed based on the content of the entity-body,
	1378	including any content-coding that has been applied, but not including
	1379	any transfer-encoding applied to the message-body. If the message is
	1380	received with a transfer-encoding, that encoding MUST be removed
	1381	prior to checking the Content-MD5 value against the received entity.
	1382
	1383	This has the result that the digest is computed on the octets of the
	1384	entity-body exactly as, and in the order that, they would be sent if
	1385	no transfer-encoding were being applied.
	1386
	1387	HTTP extends RFC 1864 to permit the digest to be computed for MIME
	1388	composite media-types (e.g., multipart/* and message/rfc822), but
	1389	this does not change how the digest is computed as defined in the
	1390	preceding paragraph.
	1391
	1392	There are several consequences of this. The entity-body for
	1393	composite types MAY contain many body-parts, each with its own MIME
	1394	and HTTP headers (including Content-MD5, Content-Transfer-Encoding,
	1395	and Content-Encoding headers). If a body-part has a Content-
	1396
	1397
	1398
	1399	Fielding, et al. Expires January 13, 2011 [Page 25]
	1400
	1401	Internet-Draft HTTP/1.1, Part 3 July 2010
	1402
	1403
	1404	Transfer-Encoding or Content-Encoding header, it is assumed that the
	1405	content of the body-part has had the encoding applied, and the body-
	1406	part is included in the Content-MD5 digest as is -- i.e., after the
	1407	application. The Transfer-Encoding header field is not allowed
	1408	within body-parts.
	1409
	1410	Conversion of all line breaks to CRLF MUST NOT be done before
	1411	computing or checking the digest: the line break convention used in
	1412	the text actually transmitted MUST be left unaltered when computing
	1413	the digest.
	1414
	1415	Note: While the definition of Content-MD5 is exactly the same for
	1416	HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
	1417	in which the application of Content-MD5 to HTTP entity-bodies
	1418	differs from its application to MIME entity-bodies. One is that
	1419	HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
	1420	does use Transfer-Encoding and Content-Encoding. Another is that
	1421	HTTP more frequently uses binary content types than MIME, so it is
	1422	worth noting that, in such cases, the byte order used to compute
	1423	the digest is the transmission byte order defined for the type.
	1424	Lastly, HTTP allows transmission of text types with any of several
	1425	line break conventions and not just the canonical form using CRLF.
	1426
	1427	5.9. Content-Type
	1428
	1429	The "Content-Type" entity-header field indicates the media type of
	1430	the entity-body. In the case of responses to the HEAD method, the
	1431	media type is that which would have been sent had the request been a
	1432	GET.
	1433
	1434	Content-Type = "Content-Type" ":" OWS Content-Type-v
	1435	Content-Type-v = media-type
	1436
	1437	Media types are defined in Section 2.3. An example of the field is
	1438
	1439	Content-Type: text/html; charset=ISO-8859-4
	1440
	1441	Further discussion of methods for identifying the media type of an
	1442	entity is provided in Section 3.2.1.
	1443
	1444	6. IANA Considerations
	1445
	1446	6.1. Message Header Registration
	1447
	1448	The Message Header Registry located at <http://www.iana.org/
	1449	assignments/message-headers/message-header-index.html> should be
	1450	updated with the permanent registrations below (see [RFC3864]):
	1451
	1452
	1453
	1454
	1455	Fielding, et al. Expires January 13, 2011 [Page 26]
	1456
	1457	Internet-Draft HTTP/1.1, Part 3 July 2010
	1458
	1459
	1460	+---------------------+----------+----------+--------------+
	1461	\| Header Field Name \| Protocol \| Status \| Reference \|
	1462	+---------------------+----------+----------+--------------+
	1463	\| Accept \| http \| standard \| Section 5.1 \|
	1464	\| Accept-Charset \| http \| standard \| Section 5.2 \|
	1465	\| Accept-Encoding \| http \| standard \| Section 5.3 \|
	1466	\| Accept-Language \| http \| standard \| Section 5.4 \|
	1467	\| Content-Disposition \| http \| \| Appendix B.1 \|
	1468	\| Content-Encoding \| http \| standard \| Section 5.5 \|
	1469	\| Content-Language \| http \| standard \| Section 5.6 \|
	1470	\| Content-Location \| http \| standard \| Section 5.7 \|
	1471	\| Content-MD5 \| http \| standard \| Section 5.8 \|
	1472	\| Content-Type \| http \| standard \| Section 5.9 \|
	1473	\| MIME-Version \| http \| \| Appendix A.1 \|
	1474	+---------------------+----------+----------+--------------+
	1475
	1476	The change controller is: "IETF (iesg@ietf.org) - Internet
	1477	Engineering Task Force".
	1478
	1479	6.2. Content Coding Registry
	1480
	1481	The registration procedure for HTTP Content Codings is now defined by
	1482	Section 2.2.1 of this document.
	1483
	1484	The HTTP Content Codings Registry located at
	1485	<http://www.iana.org/assignments/http-parameters> should be updated
	1486	with the registration below:
	1487
	1488	+----------+-----------------------------------------+--------------+
	1489	\| Name \| Description \| Reference \|
	1490	+----------+-----------------------------------------+--------------+
	1491	\| compress \| UNIX "compress" program method \| Section \|
	1492	\| \| \| 6.2.2.1 of \|
	1493	\| \| \| [Part1] \|
	1494	\| deflate \| "deflate" compression mechanism \| Section \|
	1495	\| \| ([RFC1951]) used inside the "zlib" data \| 6.2.2.2 of \|
	1496	\| \| format ([RFC1950]) \| [Part1] \|
	1497	\| gzip \| Same as GNU zip [RFC1952] \| Section \|
	1498	\| \| \| 6.2.2.3 of \|
	1499	\| \| \| [Part1] \|
	1500	\| identity \| No transformation \| Section 2.2 \|
	1501	+----------+-----------------------------------------+--------------+
	1502
	1503	7. Security Considerations
	1504
	1505	This section is meant to inform application developers, information
	1506	providers, and users of the security limitations in HTTP/1.1 as
	1507	described by this document. The discussion does not include
	1508
	1509
	1510
	1511	Fielding, et al. Expires January 13, 2011 [Page 27]
	1512
	1513	Internet-Draft HTTP/1.1, Part 3 July 2010
	1514
	1515
	1516	definitive solutions to the problems revealed, though it does make
	1517	some suggestions for reducing security risks.
	1518
	1519	7.1. Privacy Issues Connected to Accept Headers
	1520
	1521	Accept request-headers can reveal information about the user to all
	1522	servers which are accessed. The Accept-Language header in particular
	1523	can reveal information the user would consider to be of a private
	1524	nature, because the understanding of particular languages is often
	1525	strongly correlated to the membership of a particular ethnic group.
	1526	User agents which offer the option to configure the contents of an
	1527	Accept-Language header to be sent in every request are strongly
	1528	encouraged to let the configuration process include a message which
	1529	makes the user aware of the loss of privacy involved.
	1530
	1531	An approach that limits the loss of privacy would be for a user agent
	1532	to omit the sending of Accept-Language headers by default, and to ask
	1533	the user whether or not to start sending Accept-Language headers to a
	1534	server if it detects, by looking for any Vary response-header fields
	1535	generated by the server, that such sending could improve the quality
	1536	of service.
	1537
	1538	Elaborate user-customized accept header fields sent in every request,
	1539	in particular if these include quality values, can be used by servers
	1540	as relatively reliable and long-lived user identifiers. Such user
	1541	identifiers would allow content providers to do click-trail tracking,
	1542	and would allow collaborating content providers to match cross-server
	1543	click-trails or form submissions of individual users. Note that for
	1544	many users not behind a proxy, the network address of the host
	1545	running the user agent will also serve as a long-lived user
	1546	identifier. In environments where proxies are used to enhance
	1547	privacy, user agents ought to be conservative in offering accept
	1548	header configuration options to end users. As an extreme privacy
	1549	measure, proxies could filter the accept headers in relayed requests.
	1550	General purpose user agents which provide a high degree of header
	1551	configurability SHOULD warn users about the loss of privacy which can
	1552	be involved.
	1553
	1554	7.2. Content-Disposition Issues
	1555
	1556	[RFC2183], from which the often implemented Content-Disposition (see
	1557	Appendix B.1) header in HTTP is derived, has a number of very serious
	1558	security considerations. Content-Disposition is not part of the HTTP
	1559	standard, but since it is widely implemented, we are documenting its
	1560	use and risks for implementors. See Section 5 of [RFC2183] for
	1561	details.
	1562
	1563
	1564
	1565
	1566
	1567	Fielding, et al. Expires January 13, 2011 [Page 28]
	1568
	1569	Internet-Draft HTTP/1.1, Part 3 July 2010
	1570
	1571
	1572	8. Acknowledgments
	1573
	1574	9. References
	1575
	1576	9.1. Normative References
	1577
	1578	[ISO-8859-1] International Organization for Standardization,
	1579	"Information technology -- 8-bit single-byte coded
	1580	graphic character sets -- Part 1: Latin alphabet No.
	1581	1", ISO/IEC 8859-1:1998, 1998.
	1582
	1583	[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	1584	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	1585	Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs,
	1586	Connections, and Message Parsing",
	1587	draft-ietf-httpbis-p1-messaging-10 (work in progress),
	1588	July 2010.
	1589
	1590	[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	1591	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	1592	Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message
	1593	Semantics", draft-ietf-httpbis-p2-semantics-10 (work in
	1594	progress), July 2010.
	1595
	1596	[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	1597	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	1598	Ed., and J. Reschke, Ed., "HTTP/1.1, part 4:
	1599	Conditional Requests",
	1600	draft-ietf-httpbis-p4-conditional-10 (work in
	1601	progress), July 2010.
	1602
	1603	[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	1604	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	1605	Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range
	1606	Requests and Partial Responses",
	1607	draft-ietf-httpbis-p5-range-10 (work in progress),
	1608	July 2010.
	1609
	1610	[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	1611	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	1612	Ed., Nottingham, M., Ed., and J. Reschke, Ed.,
	1613	"HTTP/1.1, part 6: Caching",
	1614	draft-ietf-httpbis-p6-cache-10 (work in progress),
	1615	July 2010.
	1616
	1617	[RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field",
	1618	RFC 1864, October 1995.
	1619
	1620
	1621
	1622
	1623	Fielding, et al. Expires January 13, 2011 [Page 29]
	1624
	1625	Internet-Draft HTTP/1.1, Part 3 July 2010
	1626
	1627
	1628	[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
	1629	Format Specification version 3.3", RFC 1950, May 1996.
	1630
	1631	RFC 1950 is an Informational RFC, thus it may be less
	1632	stable than this specification. On the other hand,
	1633	this downward reference was present since the
	1634	publication of RFC 2068 in 1997 ([RFC2068]), therefore
	1635	it is unlikely to cause problems in practice. See also
	1636	[BCP97].
	1637
	1638	[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
	1639	Specification version 1.3", RFC 1951, May 1996.
	1640
	1641	RFC 1951 is an Informational RFC, thus it may be less
	1642	stable than this specification. On the other hand,
	1643	this downward reference was present since the
	1644	publication of RFC 2068 in 1997 ([RFC2068]), therefore
	1645	it is unlikely to cause problems in practice. See also
	1646	[BCP97].
	1647
	1648	[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
	1649	G. Randers-Pehrson, "GZIP file format specification
	1650	version 4.3", RFC 1952, May 1996.
	1651
	1652	RFC 1952 is an Informational RFC, thus it may be less
	1653	stable than this specification. On the other hand,
	1654	this downward reference was present since the
	1655	publication of RFC 2068 in 1997 ([RFC2068]), therefore
	1656	it is unlikely to cause problems in practice. See also
	1657	[BCP97].
	1658
	1659	[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
	1660	Mail Extensions (MIME) Part One: Format of Internet
	1661	Message Bodies", RFC 2045, November 1996.
	1662
	1663	[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
	1664	Mail Extensions (MIME) Part Two: Media Types",
	1665	RFC 2046, November 1996.
	1666
	1667	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	1668	Requirement Levels", BCP 14, RFC 2119, March 1997.
	1669
	1670	[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of
	1671	Language Tags", BCP 47, RFC 4647, September 2006.
	1672
	1673	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
	1674	Syntax Specifications: ABNF", STD 68, RFC 5234,
	1675	January 2008.
	1676
	1677
	1678
	1679	Fielding, et al. Expires January 13, 2011 [Page 30]
	1680
	1681	Internet-Draft HTTP/1.1, Part 3 July 2010
	1682
	1683
	1684	[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for
	1685	Identifying Languages", BCP 47, RFC 5646,
	1686	September 2009.
	1687
	1688	9.2. Informative References
	1689
	1690	[BCP97] Klensin, J. and S. Hartman, "Handling Normative
	1691	References to Standards-Track Documents", BCP 97,
	1692	RFC 4897, June 2007.
	1693
	1694	[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,
	1695	"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
	1696	May 1996.
	1697
	1698	[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet
	1699	Mail Extensions (MIME) Part Five: Conformance Criteria
	1700	and Examples", RFC 2049, November 1996.
	1701
	1702	[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and
	1703	T. Berners-Lee, "Hypertext Transfer Protocol --
	1704	HTTP/1.1", RFC 2068, January 1997.
	1705
	1706	[RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076,
	1707	February 1997.
	1708
	1709	[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
	1710	Presentation Information in Internet Messages: The
	1711	Content-Disposition Header Field", RFC 2183,
	1712	August 1997.
	1713
	1714	[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
	1715	Languages", BCP 18, RFC 2277, January 1998.
	1716
	1717	[RFC2295] Holtman, K. and A. Mutz, "Transparent Content
	1718	Negotiation in HTTP", RFC 2295, March 1998.
	1719
	1720	[RFC2388] Masinter, L., "Returning Values from Forms: multipart/
	1721	form-data", RFC 2388, August 1998.
	1722
	1723	[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
	1724	"MIME Encapsulation of Aggregate Documents, such as
	1725	HTML (MHTML)", RFC 2557, March 1999.
	1726
	1727	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	1728	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	1729	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	1730
	1731	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	1732
	1733
	1734
	1735	Fielding, et al. Expires January 13, 2011 [Page 31]
	1736
	1737	Internet-Draft HTTP/1.1, Part 3 July 2010
	1738
	1739
	1740	10646", RFC 3629, STD 63, November 2003.
	1741
	1742	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	1743	Procedures for Message Header Fields", BCP 90,
	1744	RFC 3864, September 2004.
	1745
	1746	[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications
	1747	and Registration Procedures", BCP 13, RFC 4288,
	1748	December 2005.
	1749
	1750	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
	1751	an IANA Considerations Section in RFCs", BCP 26,
	1752	RFC 5226, May 2008.
	1753
	1754	[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
	1755	October 2008.
	1756
	1757	Appendix A. Differences Between HTTP Entities and RFC 2045 Entities
	1758
	1759	HTTP/1.1 uses many of the constructs defined for Internet Mail
	1760	([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME
	1761	[RFC2045]) to allow entities to be transmitted in an open variety of
	1762	representations and with extensible mechanisms. However, RFC 2045
	1763	discusses mail, and HTTP has a few features that are different from
	1764	those described in RFC 2045. These differences were carefully chosen
	1765	to optimize performance over binary connections, to allow greater
	1766	freedom in the use of new media types, to make date comparisons
	1767	easier, and to acknowledge the practice of some early HTTP servers
	1768	and clients.
	1769
	1770	This appendix describes specific areas where HTTP differs from RFC
	1771	2045. Proxies and gateways to strict MIME environments SHOULD be
	1772	aware of these differences and provide the appropriate conversions
	1773	where necessary. Proxies and gateways from MIME environments to HTTP
	1774	also need to be aware of the differences because some conversions
	1775	might be required.
	1776
	1777	A.1. MIME-Version
	1778
	1779	HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages
	1780	MAY include a single MIME-Version general-header field to indicate
	1781	what version of the MIME protocol was used to construct the message.
	1782	Use of the MIME-Version header field indicates that the message is in
	1783	full compliance with the MIME protocol (as defined in [RFC2045]).
	1784	Proxies/gateways are responsible for ensuring full compliance (where
	1785	possible) when exporting HTTP messages to strict MIME environments.
	1786
	1787	MIME-Version = "MIME-Version" ":" OWS MIME-Version-v
	1788
	1789
	1790
	1791	Fielding, et al. Expires January 13, 2011 [Page 32]
	1792
	1793	Internet-Draft HTTP/1.1, Part 3 July 2010
	1794
	1795
	1796	MIME-Version-v = 1DIGIT "." 1DIGIT
	1797
	1798	MIME version "1.0" is the default for use in HTTP/1.1. However,
	1799	HTTP/1.1 message parsing and semantics are defined by this document
	1800	and not the MIME specification.
	1801
	1802	A.2. Conversion to Canonical Form
	1803
	1804	[RFC2045] requires that an Internet mail entity be converted to
	1805	canonical form prior to being transferred, as described in Section 4
	1806	of [RFC2049]. Section 2.3.1 of this document describes the forms
	1807	allowed for subtypes of the "text" media type when transmitted over
	1808	HTTP. [RFC2046] requires that content with a type of "text"
	1809	represent line breaks as CRLF and forbids the use of CR or LF outside
	1810	of line break sequences. HTTP allows CRLF, bare CR, and bare LF to
	1811	indicate a line break within text content when a message is
	1812	transmitted over HTTP.
	1813
	1814	Where it is possible, a proxy or gateway from HTTP to a strict MIME
	1815	environment SHOULD translate all line breaks within the text media
	1816	types described in Section 2.3.1 of this document to the RFC 2049
	1817	canonical form of CRLF. Note, however, that this might be
	1818	complicated by the presence of a Content-Encoding and by the fact
	1819	that HTTP allows the use of some character sets which do not use
	1820	octets 13 and 10 to represent CR and LF, as is the case for some
	1821	multi-byte character sets.
	1822
	1823	Implementors should note that conversion will break any cryptographic
	1824	checksums applied to the original content unless the original content
	1825	is already in canonical form. Therefore, the canonical form is
	1826	recommended for any content that uses such checksums in HTTP.
	1827
	1828	A.3. Conversion of Date Formats
	1829
	1830	HTTP/1.1 uses a restricted set of date formats (Section 6.1 of
	1831	[Part1]) to simplify the process of date comparison. Proxies and
	1832	gateways from other protocols SHOULD ensure that any Date header
	1833	field present in a message conforms to one of the HTTP/1.1 formats
	1834	and rewrite the date if necessary.
	1835
	1836	A.4. Introduction of Content-Encoding
	1837
	1838	RFC 2045 does not include any concept equivalent to HTTP/1.1's
	1839	Content-Encoding header field. Since this acts as a modifier on the
	1840	media type, proxies and gateways from HTTP to MIME-compliant
	1841	protocols MUST either change the value of the Content-Type header
	1842	field or decode the entity-body before forwarding the message. (Some
	1843	experimental applications of Content-Type for Internet mail have used
	1844
	1845
	1846
	1847	Fielding, et al. Expires January 13, 2011 [Page 33]
	1848
	1849	Internet-Draft HTTP/1.1, Part 3 July 2010
	1850
	1851
	1852	a media-type parameter of ";conversions=<content-coding>" to perform
	1853	a function equivalent to Content-Encoding. However, this parameter
	1854	is not part of RFC 2045).
	1855
	1856	A.5. No Content-Transfer-Encoding
	1857
	1858	HTTP does not use the Content-Transfer-Encoding field of RFC 2045.
	1859	Proxies and gateways from MIME-compliant protocols to HTTP MUST
	1860	remove any Content-Transfer-Encoding prior to delivering the response
	1861	message to an HTTP client.
	1862
	1863	Proxies and gateways from HTTP to MIME-compliant protocols are
	1864	responsible for ensuring that the message is in the correct format
	1865	and encoding for safe transport on that protocol, where "safe
	1866	transport" is defined by the limitations of the protocol being used.
	1867	Such a proxy or gateway SHOULD label the data with an appropriate
	1868	Content-Transfer-Encoding if doing so will improve the likelihood of
	1869	safe transport over the destination protocol.
	1870
	1871	A.6. Introduction of Transfer-Encoding
	1872
	1873	HTTP/1.1 introduces the Transfer-Encoding header field (Section 9.7
	1874	of [Part1]). Proxies/gateways MUST remove any transfer-coding prior
	1875	to forwarding a message via a MIME-compliant protocol.
	1876
	1877	A.7. MHTML and Line Length Limitations
	1878
	1879	HTTP implementations which share code with MHTML [RFC2557]
	1880	implementations need to be aware of MIME line length limitations.
	1881	Since HTTP does not have this limitation, HTTP does not fold long
	1882	lines. MHTML messages being transported by HTTP follow all
	1883	conventions of MHTML, including line length limitations and folding,
	1884	canonicalization, etc., since HTTP transports all message-bodies as
	1885	payload (see Section 2.3.2) and does not interpret the content or any
	1886	MIME header lines that might be contained therein.
	1887
	1888	Appendix B. Additional Features
	1889
	1890	[RFC1945] and [RFC2068] document protocol elements used by some
	1891	existing HTTP implementations, but not consistently and correctly
	1892	across most HTTP/1.1 applications. Implementors are advised to be
	1893	aware of these features, but cannot rely upon their presence in, or
	1894	interoperability with, other HTTP/1.1 applications. Some of these
	1895	describe proposed experimental features, and some describe features
	1896	that experimental deployment found lacking that are now addressed in
	1897	the base HTTP/1.1 specification.
	1898
	1899	A number of other headers, such as Content-Disposition and Title,
	1900
	1901
	1902
	1903	Fielding, et al. Expires January 13, 2011 [Page 34]
	1904
	1905	Internet-Draft HTTP/1.1, Part 3 July 2010
	1906
	1907
	1908	from SMTP and MIME are also often implemented (see [RFC2076]).
	1909
	1910	B.1. Content-Disposition
	1911
	1912	The "Content-Disposition" response-header field has been proposed as
	1913	a means for the origin server to suggest a default filename if the
	1914	user requests that the content is saved to a file. This usage is
	1915	derived from the definition of Content-Disposition in [RFC2183].
	1916
	1917	content-disposition = "Content-Disposition" ":" OWS
	1918	content-disposition-v
	1919	content-disposition-v = disposition-type
	1920	*( OWS ";" OWS disposition-parm )
	1921	disposition-type = "attachment" / disp-extension-token
	1922	disposition-parm = filename-parm / disp-extension-parm
	1923	filename-parm = "filename" "=" quoted-string
	1924	disp-extension-token = token
	1925	disp-extension-parm = token "=" word
	1926
	1927	An example is
	1928
	1929	Content-Disposition: attachment; filename="fname.ext"
	1930
	1931	The receiving user agent SHOULD NOT respect any directory path
	1932	information present in the filename-parm parameter, which is the only
	1933	parameter believed to apply to HTTP implementations at this time.
	1934	The filename SHOULD be treated as a terminal component only.
	1935
	1936	If this header is used in a response with the application/
	1937	octet-stream content-type, the implied suggestion is that the user
	1938	agent should not display the response, but directly enter a "save
	1939	response as..." dialog.
	1940
	1941	See Section 7.2 for Content-Disposition security issues.
	1942
	1943	Appendix C. Compatibility with Previous Versions
	1944
	1945	C.1. Changes from RFC 2068
	1946
	1947	Transfer-coding and message lengths all interact in ways that
	1948	required fixing exactly when chunked encoding is used (to allow for
	1949	transfer encoding that may not be self delimiting); it was important
	1950	to straighten out exactly how message lengths are computed.
	1951	(Section 3.2.2, see also [Part1], [Part5] and [Part6]).
	1952
	1953	Charset wildcarding is introduced to avoid explosion of character set
	1954	names in accept headers. (Section 5.2)
	1955
	1956
	1957
	1958
	1959	Fielding, et al. Expires January 13, 2011 [Page 35]
	1960
	1961	Internet-Draft HTTP/1.1, Part 3 July 2010
	1962
	1963
	1964	Content-Base was deleted from the specification: it was not
	1965	implemented widely, and there is no simple, safe way to introduce it
	1966	without a robust extension mechanism. In addition, it is used in a
	1967	similar, but not identical fashion in MHTML [RFC2557].
	1968
	1969	A content-coding of "identity" was introduced, to solve problems
	1970	discovered in caching. (Section 2.2)
	1971
	1972	The Alternates, Content-Version, Derived-From, Link, URI, Public and
	1973	Content-Base header fields were defined in previous versions of this
	1974	specification, but not commonly implemented. See Section 19.6.2 of
	1975	[RFC2068].
	1976
	1977	C.2. Changes from RFC 2616
	1978
	1979	Clarify contexts that charset is used in. (Section 2.1)
	1980
	1981	Remove base URI setting semantics for Content-Location due to poor
	1982	implementation support, which was caused by too many broken servers
	1983	emitting bogus Content-Location headers, and also the potentially
	1984	undesirable effect of potentially breaking relative links in content-
	1985	negotiated resources. (Section 5.7)
	1986
	1987	Remove reference to non-existant identity transfer-coding value
	1988	tokens. (Appendix A.5)
	1989
	1990	Appendix D. Collected ABNF
	1991
	1992	Accept = "Accept:" OWS Accept-v
	1993	Accept-Charset = "Accept-Charset:" OWS Accept-Charset-v
	1994	Accept-Charset-v = ( "," OWS ) ( charset / "" ) [ OWS ";" OWS "q="
	1995	qvalue ] ( OWS "," [ OWS ( charset / "" ) [ OWS ";" OWS "q="
	1996	qvalue ] ] )
	1997	Accept-Encoding = "Accept-Encoding:" OWS Accept-Encoding-v
	1998	Accept-Encoding-v = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] )
	1999	) *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ]
	2000	Accept-Language = "Accept-Language:" OWS Accept-Language-v
	2001	Accept-Language-v = *( "," OWS ) language-range [ OWS ";" OWS "q="
	2002	qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ]
	2003	] )
	2004	Accept-v = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
	2005	OWS media-range [ accept-params ] ] ) ]
	2006
	2007	Content-Encoding = "Content-Encoding:" OWS Content-Encoding-v
	2008	Content-Encoding-v = ( "," OWS ) content-coding ( OWS "," [ OWS
	2009	content-coding ] )
	2010	Content-Language = "Content-Language:" OWS Content-Language-v
	2011
	2012
	2013
	2014
	2015	Fielding, et al. Expires January 13, 2011 [Page 36]
	2016
	2017	Internet-Draft HTTP/1.1, Part 3 July 2010
	2018
	2019
	2020	Content-Language-v = ( "," OWS ) language-tag ( OWS "," [ OWS
	2021	language-tag ] )
	2022	Content-Length = <Content-Length, defined in [Part1], Section 9.2>
	2023	Content-Location = "Content-Location:" OWS Content-Location-v
	2024	Content-Location-v = absolute-URI / partial-URI
	2025	Content-MD5 = "Content-MD5:" OWS Content-MD5-v
	2026	Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]>
	2027	Content-Range = <Content-Range, defined in [Part5], Section 5.2>
	2028	Content-Type = "Content-Type:" OWS Content-Type-v
	2029	Content-Type-v = media-type
	2030
	2031	Expires = <Expires, defined in [Part6], Section 3.3>
	2032
	2033	Last-Modified = <Last-Modified, defined in [Part4], Section 6.6>
	2034
	2035	MIME-Version = "MIME-Version:" OWS MIME-Version-v
	2036	MIME-Version-v = 1DIGIT "." 1DIGIT
	2037
	2038	OWS = <OWS, defined in [Part1], Section 1.2.2>
	2039
	2040	absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
	2041	accept-ext = OWS ";" OWS token [ "=" word ]
	2042	accept-params = OWS ";" OWS "q=" qvalue *accept-ext
	2043	attribute = token
	2044
	2045	charset = token
	2046	codings = ( content-coding / "*" )
	2047	content-coding = token
	2048	content-disposition = "Content-Disposition:" OWS
	2049	content-disposition-v
	2050	content-disposition-v = disposition-type *( OWS ";" OWS
	2051	disposition-parm )
	2052
	2053	disp-extension-parm = token "=" word
	2054	disp-extension-token = token
	2055	disposition-parm = filename-parm / disp-extension-parm
	2056	disposition-type = "attachment" / disp-extension-token
	2057
	2058	entity-body = *OCTET
	2059	entity-header = Content-Encoding / Content-Language / Content-Length
	2060	/ Content-Location / Content-MD5 / Content-Range / Content-Type /
	2061	Expires / Last-Modified / extension-header
	2062	extension-header = header-field
	2063
	2064	filename-parm = "filename=" quoted-string
	2065
	2066	header-field = <header-field, defined in [Part1], Section 3.2>
	2067
	2068
	2069
	2070
	2071	Fielding, et al. Expires January 13, 2011 [Page 37]
	2072
	2073	Internet-Draft HTTP/1.1, Part 3 July 2010
	2074
	2075
	2076	language-range = <language-range, defined in [RFC4647], Section 2.1>
	2077	language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>
	2078
	2079	media-range = ( "/" / ( type "/" ) / ( type "/" subtype ) ) ( OWS
	2080	";" OWS parameter )
	2081	media-type = type "/" subtype *( OWS ";" OWS parameter )
	2082
	2083	parameter = attribute "=" value
	2084	partial-URI = <partial-URI, defined in [Part1], Section 2.6>
	2085
	2086	quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
	2087	qvalue = <qvalue, defined in [Part1], Section 6.4>
	2088
	2089	subtype = token
	2090
	2091	token = <token, defined in [Part1], Section 1.2.2>
	2092	type = token
	2093
	2094	value = word
	2095
	2096	word = <word, defined in [Part1], Section 1.2.2>
	2097
	2098	ABNF diagnostics:
	2099
	2100	; Accept defined but not used
	2101	; Accept-Charset defined but not used
	2102	; Accept-Encoding defined but not used
	2103	; Accept-Language defined but not used
	2104	; MIME-Version defined but not used
	2105	; content-disposition defined but not used
	2106	; entity-body defined but not used
	2107	; entity-header defined but not used
	2108
	2109	Appendix E. Change Log (to be removed by RFC Editor before publication)
	2110
	2111	E.1. Since RFC2616
	2112
	2113	Extracted relevant partitions from [RFC2616].
	2114
	2115	E.2. Since draft-ietf-httpbis-p3-payload-00
	2116
	2117	Closed issues:
	2118
	2119	o <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type
	2120	Registrations" (<http://purl.org/NET/http-errata#media-reg>)
	2121
	2122	o <http://tools.ietf.org/wg/httpbis/trac/ticket/14>: "Clarification
	2123	regarding quoting of charset values"
	2124
	2125
	2126
	2127	Fielding, et al. Expires January 13, 2011 [Page 38]
	2128
	2129	Internet-Draft HTTP/1.1, Part 3 July 2010
	2130
	2131
	2132	(<http://purl.org/NET/http-errata#charactersets>)
	2133
	2134	o <http://tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove
	2135	'identity' token references"
	2136	(<http://purl.org/NET/http-errata#identity>)
	2137
	2138	o <http://tools.ietf.org/wg/httpbis/trac/ticket/25>: "Accept-
	2139	Encoding BNF"
	2140
	2141	o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
	2142	Informative references"
	2143
	2144	o <http://tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700
	2145	references"
	2146
	2147	o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to
	2148	RFC4288"
	2149
	2150	o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
	2151	references"
	2152
	2153	o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1
	2154	Reference"
	2155
	2156	o <http://tools.ietf.org/wg/httpbis/trac/ticket/68>: "Encoding
	2157	References Normative"
	2158
	2159	o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
	2160	to-date references"
	2161
	2162	E.3. Since draft-ietf-httpbis-p3-payload-01
	2163
	2164	Ongoing work on ABNF conversion
	2165	(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
	2166
	2167	o Add explicit references to BNF syntax and rules imported from
	2168	other parts of the specification.
	2169
	2170	E.4. Since draft-ietf-httpbis-p3-payload-02
	2171
	2172	Closed issues:
	2173
	2174	o <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting
	2175	Charsets"
	2176
	2177	o <http://tools.ietf.org/wg/httpbis/trac/ticket/105>:
	2178	"Classification for Allow header"
	2179
	2180
	2181
	2182
	2183	Fielding, et al. Expires January 13, 2011 [Page 39]
	2184
	2185	Internet-Draft HTTP/1.1, Part 3 July 2010
	2186
	2187
	2188	o <http://tools.ietf.org/wg/httpbis/trac/ticket/115>: "missing
	2189	default for qvalue in description of Accept-Encoding"
	2190
	2191	Ongoing work on IANA Message Header Registration
	2192	(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
	2193
	2194	o Reference RFC 3984, and update header registrations for headers
	2195	defined in this document.
	2196
	2197	E.5. Since draft-ietf-httpbis-p3-payload-03
	2198
	2199	Closed issues:
	2200
	2201	o <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting
	2202	Charsets"
	2203
	2204	o <http://tools.ietf.org/wg/httpbis/trac/ticket/113>: "language tag
	2205	matching (Accept-Language) vs RFC4647"
	2206
	2207	o <http://tools.ietf.org/wg/httpbis/trac/ticket/121>: "RFC 1806 has
	2208	been replaced by RFC2183"
	2209
	2210	Other changes:
	2211
	2212	o <http://tools.ietf.org/wg/httpbis/trac/ticket/68>: "Encoding
	2213	References Normative" -- rephrase the annotation and reference
	2214	[BCP97].
	2215
	2216	E.6. Since draft-ietf-httpbis-p3-payload-04
	2217
	2218	Closed issues:
	2219
	2220	o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is
	2221	updated by RFC 5322"
	2222
	2223	Ongoing work on ABNF conversion
	2224	(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
	2225
	2226	o Use "/" instead of "\|" for alternatives.
	2227
	2228	o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
	2229	whitespace ("OWS") and required whitespace ("RWS").
	2230
	2231	o Rewrite ABNFs to spell out whitespace rules, factor out header
	2232	value format definitions.
	2233
	2234
	2235
	2236
	2237
	2238
	2239	Fielding, et al. Expires January 13, 2011 [Page 40]
	2240
	2241	Internet-Draft HTTP/1.1, Part 3 July 2010
	2242
	2243
	2244	E.7. Since draft-ietf-httpbis-p3-payload-05
	2245
	2246	Closed issues:
	2247
	2248	o <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join
	2249	"Differences Between HTTP Entities and RFC 2045 Entities"?"
	2250
	2251	Final work on ABNF conversion
	2252	(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
	2253
	2254	o Add appendix containing collected and expanded ABNF, reorganize
	2255	ABNF introduction.
	2256
	2257	Other changes:
	2258
	2259	o Move definition of quality values into Part 1.
	2260
	2261	E.8. Since draft-ietf-httpbis-p3-payload-06
	2262
	2263	Closed issues:
	2264
	2265	o <http://tools.ietf.org/wg/httpbis/trac/ticket/80>: "Content-
	2266	Location isn't special"
	2267
	2268	o <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content
	2269	Sniffing"
	2270
	2271	E.9. Since draft-ietf-httpbis-p3-payload-07
	2272
	2273	Closed issues:
	2274
	2275	o <http://tools.ietf.org/wg/httpbis/trac/ticket/13>: "Updated
	2276	reference for language tags"
	2277
	2278	o <http://tools.ietf.org/wg/httpbis/trac/ticket/110>: "Clarify rules
	2279	for determining what entities a response carries"
	2280
	2281	o <http://tools.ietf.org/wg/httpbis/trac/ticket/154>: "Content-
	2282	Location base-setting problems"
	2283
	2284	o <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content
	2285	Sniffing"
	2286
	2287	o <http://tools.ietf.org/wg/httpbis/trac/ticket/188>: "pick IANA
	2288	policy (RFC5226) for Transfer Coding / Content Coding"
	2289
	2290	o <http://tools.ietf.org/wg/httpbis/trac/ticket/189>: "move
	2291	definitions of gzip/deflate/compress to part 1"
	2292
	2293
	2294
	2295	Fielding, et al. Expires January 13, 2011 [Page 41]
	2296
	2297	Internet-Draft HTTP/1.1, Part 3 July 2010
	2298
	2299
	2300	Partly resolved issues:
	2301
	2302	o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA
	2303	requirements wrt Transfer-Coding values" (add the IANA
	2304	Considerations subsection)
	2305
	2306	o <http://tools.ietf.org/wg/httpbis/trac/ticket/149>: "update IANA
	2307	requirements wrt Content-Coding values" (add the IANA
	2308	Considerations subsection)
	2309
	2310	E.10. Since draft-ietf-httpbis-p3-payload-08
	2311
	2312	Closed issues:
	2313
	2314	o <http://tools.ietf.org/wg/httpbis/trac/ticket/81>: "Content
	2315	Negotiation for media types"
	2316
	2317	o <http://tools.ietf.org/wg/httpbis/trac/ticket/181>: "Accept-
	2318	Language: which RFC4647 filtering?"
	2319
	2320	E.11. Since draft-ietf-httpbis-p3-payload-09
	2321
	2322	Closed issues:
	2323
	2324	o <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry
	2325	for content/transfer encodings"
	2326
	2327	o <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content
	2328	Sniffing"
	2329
	2330	o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term
	2331	"word" when talking about header structure"
	2332
	2333	Partly resolved issues:
	2334
	2335	o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
	2336	requested resource's URI"
	2337
	2338	Index
	2339
	2340	A
	2341	Accept header 17
	2342	Accept-Charset header 19
	2343	Accept-Encoding header 20
	2344	Accept-Language header 21
	2345	Alternates header 36
	2346
	2347	C
	2348
	2349
	2350
	2351	Fielding, et al. Expires January 13, 2011 [Page 42]
	2352
	2353	Internet-Draft HTTP/1.1, Part 3 July 2010
	2354
	2355
	2356	Coding Format
	2357	compress 8
	2358	deflate 8
	2359	gzip 9
	2360	identity 9
	2361	compress (Coding Format) 8
	2362	content negotiation 5
	2363	Content-Base header 36
	2364	Content-Disposition header 35
	2365	Content-Encoding header 22
	2366	Content-Language header 23
	2367	Content-Location header 24
	2368	Content-MD5 header 25
	2369	Content-Type header 26
	2370	Content-Version header 36
	2371
	2372	D
	2373	deflate (Coding Format) 8
	2374	Derived-From header 36
	2375
	2376	E
	2377	entity 5
	2378
	2379	G
	2380	Grammar
	2381	Accept 17
	2382	Accept-Charset 19
	2383	Accept-Charset-v 19
	2384	Accept-Encoding 20
	2385	Accept-Encoding-v 20
	2386	accept-ext 17
	2387	Accept-Language 21
	2388	Accept-Language-v 21
	2389	accept-params 17
	2390	Accept-v 17
	2391	attribute 10
	2392	charset 7
	2393	codings 20
	2394	content-coding 8
	2395	content-disposition 35
	2396	content-disposition-v 35
	2397	Content-Encoding 22
	2398	Content-Encoding-v 22
	2399	Content-Language 23
	2400	Content-Language-v 23
	2401	Content-Location 24
	2402	Content-Location-v 24
	2403	Content-MD5 25
	2404
	2405
	2406
	2407	Fielding, et al. Expires January 13, 2011 [Page 43]
	2408
	2409	Internet-Draft HTTP/1.1, Part 3 July 2010
	2410
	2411
	2412	Content-MD5-v 25
	2413	Content-Type 26
	2414	Content-Type-v 26
	2415	disp-extension-parm 35
	2416	disp-extension-token 35
	2417	disposition-parm 35
	2418	disposition-type 35
	2419	entity-body 13
	2420	entity-header 13
	2421	extension-header 13
	2422	filename-parm 35
	2423	language-range 21
	2424	language-tag 12
	2425	media-range 17
	2426	media-type 9
	2427	MIME-Version 32
	2428	MIME-Version-v 32
	2429	parameter 10
	2430	subtype 9
	2431	type 9
	2432	value 10
	2433	gzip (Coding Format) 9
	2434
	2435	H
	2436	Headers
	2437	Accept 17
	2438	Accept-Charset 19
	2439	Accept-Encoding 20
	2440	Accept-Language 21
	2441	Alternate 36
	2442	Content-Base 36
	2443	Content-Disposition 35
	2444	Content-Encoding 22
	2445	Content-Language 23
	2446	Content-Location 24
	2447	Content-MD5 25
	2448	Content-Type 26
	2449	Content-Version 36
	2450	Derived-From 36
	2451	Link 36
	2452	MIME-Version 32
	2453	Public 36
	2454	URI 36
	2455
	2456	I
	2457	identity (Coding Format) 9
	2458
	2459	L
	2460
	2461
	2462
	2463	Fielding, et al. Expires January 13, 2011 [Page 44]
	2464
	2465	Internet-Draft HTTP/1.1, Part 3 July 2010
	2466
	2467
	2468	Link header 36
	2469
	2470	M
	2471	MIME-Version header 32
	2472
	2473	P
	2474	Public header 36
	2475
	2476	R
	2477	representation 5
	2478
	2479	U
	2480	URI header 36
	2481
	2482	V
	2483	variant 5
	2484
	2485	Authors' Addresses
	2486
	2487	Roy T. Fielding (editor)
	2488	Day Software
	2489	23 Corporate Plaza DR, Suite 280
	2490	Newport Beach, CA 92660
	2491	USA
	2492
	2493	Phone: +1-949-706-5300
	2494	Fax: +1-949-706-5305
	2495	EMail: fielding@gbiv.com
	2496	URI: http://roy.gbiv.com/
	2497
	2498
	2499	Jim Gettys
	2500	Alcatel-Lucent Bell Labs
	2501	21 Oak Knoll Road
	2502	Carlisle, MA 01741
	2503	USA
	2504
	2505	EMail: jg@freedesktop.org
	2506	URI: http://gettys.wordpress.com/
	2507
	2508
	2509
	2510
	2511
	2512
	2513
	2514
	2515
	2516
	2517
	2518
	2519	Fielding, et al. Expires January 13, 2011 [Page 45]
	2520
	2521	Internet-Draft HTTP/1.1, Part 3 July 2010
	2522
	2523
	2524	Jeffrey C. Mogul
	2525	Hewlett-Packard Company
	2526	HP Labs, Large Scale Systems Group
	2527	1501 Page Mill Road, MS 1177
	2528	Palo Alto, CA 94304
	2529	USA
	2530
	2531	EMail: JeffMogul@acm.org
	2532
	2533
	2534	Henrik Frystyk Nielsen
	2535	Microsoft Corporation
	2536	1 Microsoft Way
	2537	Redmond, WA 98052
	2538	USA
	2539
	2540	EMail: henrikn@microsoft.com
	2541
	2542
	2543	Larry Masinter
	2544	Adobe Systems, Incorporated
	2545	345 Park Ave
	2546	San Jose, CA 95110
	2547	USA
	2548
	2549	EMail: LMM@acm.org
	2550	URI: http://larry.masinter.net/
	2551
	2552
	2553	Paul J. Leach
	2554	Microsoft Corporation
	2555	1 Microsoft Way
	2556	Redmond, WA 98052
	2557
	2558	EMail: paulle@microsoft.com
	2559
	2560
	2561	Tim Berners-Lee
	2562	World Wide Web Consortium
	2563	MIT Computer Science and Artificial Intelligence Laboratory
	2564	The Stata Center, Building 32
	2565	32 Vassar Street
	2566	Cambridge, MA 02139
	2567	USA
	2568
	2569	EMail: timbl@w3.org
	2570	URI: http://www.w3.org/People/Berners-Lee/
	2571
	2572
	2573
	2574
	2575	Fielding, et al. Expires January 13, 2011 [Page 46]
	2576
	2577	Internet-Draft HTTP/1.1, Part 3 July 2010
	2578
	2579
	2580	Yves Lafon (editor)
	2581	World Wide Web Consortium
	2582	W3C / ERCIM
	2583	2004, rte des Lucioles
	2584	Sophia-Antipolis, AM 06902
	2585	France
	2586
	2587	EMail: ylafon@w3.org
	2588	URI: http://www.raubacapeu.net/people/yves/
	2589
	2590
	2591	Julian F. Reschke (editor)
	2592	greenbytes GmbH
	2593	Hafenweg 16
	2594	Muenster, NW 48155
	2595	Germany
	2596
	2597	Phone: +49 251 2807760
	2598	Fax: +49 251 2807761
	2599	EMail: julian.reschke@greenbytes.de
	2600	URI: http://greenbytes.de/tech/webdav/
	2601
	2602
	2603
	2604
	2605
	2606
	2607
	2608
	2609
	2610
	2611
	2612
	2613
	2614
	2615
	2616
	2617
	2618
	2619
	2620
	2621
	2622
	2623
	2624
	2625
	2626
	2627
	2628
	2629
	2630
	2631	Fielding, et al. Expires January 13, 2011 [Page 47]
	2632

Note: See TracBrowser for help on using the repository browser.

Context Navigation

source: draft-ietf-httpbis/10/draft-ietf-httpbis-p3-payload-10.txt @ 956

Download in other formats: