Context Navigation

source: draft-ietf-httpbis/latest/auth48/rfc7233.abdiff.txt @ 2676

Last change on this file since 2676 was 2676, checked in by julian.reschke@…, 9 years ago
add RFC7233-to-be (#553)
Property svn:eol-style set to `native`
File size: 25.8 KB

Line
1
2	INTRODUCTION, paragraph 1:
3	OLD:
4
5	HTTPbis Working Group R. Fielding, Ed.
6	Internet-Draft Adobe
7	Obsoletes: 2616 (if approved) Y. Lafon, Ed.
8	Intended status: Standards Track W3C
9	Expires: November 16, 2014 J. Reschke, Ed.
10	greenbytes
11	May 15, 2014
12
13	NEW:
14
15	Internet Engineering Task Force (IETF) R. Fielding, Ed.
16	Request for Comments: 7233 Adobe
17	Obsoletes: 2616 Y. Lafon, Ed.
18	Category: Standards Track W3C
19	ISSN: 2070-1721 J. Reschke, Ed.
20	greenbytes
21	May 2014
22
23
24	INTRODUCTION, paragraph 2:
25	OLD:
26
27	Hypertext Transfer Protocol (HTTP/1.1): Range Requests
28	draft-ietf-httpbis-p5-range-latest
29
30	NEW:
31
32	Hypertext Transfer Protocol (HTTP/1.1): Range Requests
33
34
35	INTRODUCTION, paragraph 5:
36	OLD:
37
38	Editorial Note (To be removed by RFC Editor)
39
40	Discussion of this draft takes place on the HTTPBIS working group
41	mailing list (ietf-http-wg@w3.org), which is archived at
42	<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
43
44	The current issues list is at
45	<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
46	documents (including fancy diffs) can be found at
47	<http://tools.ietf.org/wg/httpbis/>.
48
49	_This is a temporary document for the purpose of tracking the
50	editorial changes made during the AUTH48 (RFC publication) phase._
51
52	Status of This Memo
53
54	NEW:
55
56	Status of This Memo
57
58
59	INTRODUCTION, paragraph 6:
60	OLD:
61
62	This Internet-Draft is submitted in full conformance with the
63	provisions of BCP 78 and BCP 79.
64
65	NEW:
66
67	This is an Internet Standards Track document.
68
69
70	INTRODUCTION, paragraph 7:
71	OLD:
72
73	Internet-Drafts are working documents of the Internet Engineering
74	Task Force (IETF). Note that other groups may also distribute
75	working documents as Internet-Drafts. The list of current Internet-
76	Drafts is at http://datatracker.ietf.org/drafts/current/.
77
78	NEW:
79
80	This document is a product of the Internet Engineering Task Force
81	(IETF). It represents the consensus of the IETF community. It has
82	received public review and has been approved for publication by the
83	Internet Engineering Steering Group (IESG). Further information on
84	Internet Standards is available in Section 2 of RFC 5741.
85
86
87	INTRODUCTION, paragraph 8:
88	OLD:
89
90	Internet-Drafts are draft documents valid for a maximum of six months
91	and may be updated, replaced, or obsoleted by other documents at any
92	time. It is inappropriate to use Internet-Drafts as reference
93	material or to cite them other than as "work in progress."
94	This Internet-Draft will expire on November 16, 2014.
95
96	NEW:
97
98	Information about the current status of this document, any errata,
99	and how to provide feedback on it may be obtained at
100	http://www.rfc-editor.org/info/rfc7233.
101
102
103	INTRODUCTION, paragraph 14:
104	OLD:
105
106	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
107	1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4
108	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
109	2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4
110	2.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 5
111	2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 7
112	2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7
113	3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . . 7
114	3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 7
115	3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9
116	4. Responses to a Range Request . . . . . . . . . . . . . . . . . 10
117	4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 10
118	4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 12
119	4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14
120	4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 15
121	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
122	5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15
123	5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15
124	5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 16
125	5.2. Status Code Registration . . . . . . . . . . . . . . . . . 16
126	5.3. Header Field Registration . . . . . . . . . . . . . . . . 16
127	5.4. Internet Media Type Registration . . . . . . . . . . . . . 17
128	5.4.1. Internet Media Type multipart/byteranges . . . . . . . 17
129	6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
130	6.1. Denial of Service Attacks using Range . . . . . . . . . . 18
131	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
132	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
133	8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
134	8.2. Informative References . . . . . . . . . . . . . . . . . . 19
135	Appendix A. Internet Media Type multipart/byteranges . . . . . . 20
136	Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 21
137	Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21
138	Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21
139	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
140
141	NEW:
142
143	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
144	1.1. Conformance and Error Handling . . . . . . . . . . . . . . 3
145	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 3
146	2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 3
147	2.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 4
148	2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 6
149	2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 6
150	3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . . 6
151	3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 6
152	3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 8
153	4. Responses to a Range Request . . . . . . . . . . . . . . . . . 9
154	4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 9
155	4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 11
156	4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 13
157	4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 14
158	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
159	5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 14
160	5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 14
161	5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 15
162	5.2. Status Code Registration . . . . . . . . . . . . . . . . . 15
163	5.3. Header Field Registration . . . . . . . . . . . . . . . . 15
164	5.4. Internet Media Type Registration . . . . . . . . . . . . . 16
165	5.4.1. Internet Media Type multipart/byteranges . . . . . . . 16
166	6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
167	6.1. Denial-of-Service Attacks Using Range . . . . . . . . . . 17
168	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
169	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
170	8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
171	8.2. Informative References . . . . . . . . . . . . . . . . . . 18
172	Appendix A. Internet Media Type multipart/byteranges . . . . . . 19
173	Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20
174	Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 20
175	Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 20
176	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
177
178
179	Section 1., paragraph 2:
180	OLD:
181
182	This document defines HTTP/1.1 range requests, partial responses, and
183	the multipart/byteranges media type. Range requests are an OPTIONAL
184	feature of HTTP, designed so that recipients not implementing this
185	feature (or not supporting it for the target resource) can respond as
186	if it is a normal GET request without impacting interoperability.
187	Partial responses are indicated by a distinct status code to not be
188	mistaken for full responses by caches that might not implement the
189	feature.
190
191	NEW:
192
193	This document defines HTTP/1.1 range requests, partial responses, and
194	the multipart/byteranges media type. Range requests are an OPTIONAL
195	feature of HTTP, designed so that recipients not implementing this
196	feature (or not supporting it for the target resource) can respond as
197	if it is a normal GET request without impacting interoperability.
198	Partial responses are indicated by a distinct status code not to be
199	mistaken for full responses by caches that might not implement the
200	feature.
201
202
203	Section 2.1., paragraph 3:
204	OLD:
205
206	A byte range request can specify a single range of bytes, or a set of
207	ranges within a single representation.
208
209	NEW:
210
211	A byte-range request can specify a single range of bytes or a set of
212	ranges within a single representation.
213
214
215	Section 2.1., paragraph 26:
216	OLD:
217
218	In the byte range syntax, first-byte-pos, last-byte-pos, and suffix-
219	length are expressed as decimal number of octets. Since there is no
220	predefined limit to the length of a payload, recipients MUST
221	anticipate potentially large decimal numerals and prevent parsing
222	errors due to integer conversion overflows.
223
224	NEW:
225
226	In the byte-range syntax, first-byte-pos, last-byte-pos, and suffix-
227	length are expressed as decimal number of octets. Since there is no
228	predefined limit to the length of a payload, recipients MUST
229	anticipate potentially large decimal numerals and prevent parsing
230	errors due to integer conversion overflows.
231
232
233	Section 3.2., paragraph 2:
234	OLD:
235
236	The "If-Range" header field allows a client to "short-circuit" the
237	second request. Informally, its meaning is: if the representation is
238	unchanged, send me the part(s) that I am requesting in Range;
239	otherwise, send me the entire representation.
240
241	NEW:
242
243	The "If-Range" header field allows a client to "short-circuit" the
244	second request. Informally, its meaning is as follows: if the
245	representation is unchanged, send me the part(s) that I am requesting
246	in Range; otherwise, send me the entire representation.
247
248
249	Section 3.2., paragraph 4:
250	OLD:
251
252	A client MUST NOT generate an If-Range header field in a request that
253	does not contain a Range header field. A server MUST ignore an If-
254	Range header field received in a request that does not contain a
255	Range header field. An origin server MUST ignore an If-Range header
256	field received in a request for a target resource that does not
257	support Range requests.
258
259	NEW:
260
261	A client MUST NOT generate an If-Range header field in a request that
262	does not contain a Range header field. A server MUST ignore an
263	If-Range header field received in a request that does not contain a
264	Range header field. An origin server MUST ignore an If-Range header
265	field received in a request for a target resource that does not
266	support Range requests.
267
268
269	Section 3.2., paragraph 7:
270	OLD:
271
272	If the validator given in the If-Range header field matches the
273	current validator for the selected representation of the target
274	resource, then the server SHOULD process the Range header field as
275	requested. If the validator does not match, the server MUST ignore
276	the Range header field. Note that this comparison by exact match,
277	including when the validator is an HTTP-date, differs from the
278	"earlier than or equal to" comparison used when evaluating an If-
279	Unmodified-Since conditional.
280
281	NEW:
282
283	If the validator given in the If-Range header field matches the
284	current validator for the selected representation of the target
285	resource, then the server SHOULD process the Range header field as
286	requested. If the validator does not match, the server MUST ignore
287	the Range header field. Note that this comparison by exact match,
288	including when the validator is an HTTP-date, differs from the
289	"earlier than or equal to" comparison used when evaluating an
290	If-Unmodified-Since conditional.
291
292
293	Section 206, paragraph 0:
294	OLD:
295
296	If multiple parts are being transferred, the server generating the
297	206 response MUST generate a "multipart/byteranges" payload, as
298	defined in Appendix A, and a Content-Type header field containing the
299	multipart/byteranges media type and its required boundary parameter.
300	To avoid confusion with single part responses, a server MUST NOT
301	generate a Content-Range header field in the HTTP header section of a
302	multiple part response (this field will be sent in each part
303	instead).
304
305	NEW:
306
307	If multiple parts are being transferred, the server generating the
308	206 response MUST generate a "multipart/byteranges" payload, as
309	defined in Appendix A, and a Content-Type header field containing the
310	multipart/byteranges media type and its required boundary parameter.
311	To avoid confusion with single-part responses, a server MUST NOT
312	generate a Content-Range header field in the HTTP header section of a
313	multiple part response (this field will be sent in each part
314	instead).
315
316
317	Section 4.2., paragraph 14:
318	OLD:
319
320	A server generating a 416 (Range Not Satisfiable) response to a byte
321	range request SHOULD send a Content-Range header field with an
322	unsatisfied-range value, as in the following example:
323
324	NEW:
325
326	A server generating a 416 (Range Not Satisfiable) response to a byte-
327	range request SHOULD send a Content-Range header field with an
328	unsatisfied-range value, as in the following example:
329
330
331	Section 4.2., paragraph 17:
332	OLD:
333
334	The "Content-Range" header field has no meaning for status codes that
335	do not explicitly describe its semantic. For this specification,
336	only the 206 (Partial Content) and 416 (Range Not Satisfiable) status
337	codes describe a meaning for Content-Range.
338
339	NEW:
340
341	The Content-Range header field has no meaning for status codes that
342	do not explicitly describe its semantic. For this specification,
343	only the 206 (Partial Content) and 416 (Range Not Satisfiable) status
344	codes describe a meaning for Content-Range.
345
346
347	Section 4.3., paragraph 3:
348	OLD:
349
350	If the most recent response is an incomplete 200 (OK) response, then
351	the header fields of that response are used for any combined response
352	and replace those of the matching stored responses.
353
354	NEW:
355
356	If the most recent response is an incomplete 200 (OK) response, then
357	the header fields of that response are used for any combined response
358	and they replace those of the matching stored responses.
359
360
361	Section 4.4., paragraph 2:
362	OLD:
363
364	For byte ranges, failing to overlap the current extent means that the
365	first-byte-pos of all of the byte-range-spec values were greater than
366	the current length of the selected representation. When this status
367	code is generated in response to a byte range request, the sender
368	SHOULD generate a Content-Range header field specifying the current
369	length of the selected representation (Section 4.2).
370
371	NEW:
372
373	For byte ranges, failing to overlap the current extent means that the
374	first-byte-pos of all of the byte-range-spec values were greater than
375	the current length of the selected representation. When this status
376	code is generated in response to a byte-range request, the sender
377	SHOULD generate a Content-Range header field specifying the current
378	length of the selected representation (Section 4.2).
379
380
381	Section 5.1., paragraph 1:
382	OLD:
383
384	The HTTP Range Unit Registry defines the namespace for the range unit
385	names and refers to their corresponding specifications. The registry
386	will be created and maintained at (the suggested URI)
387	<http://www.iana.org/assignments/http-parameters>.
388
389	NEW:
390
391	The "HTTP Range Unit Registry" defines the namespace for the range
392	unit names and refers to their corresponding specifications. The
393	registry will be created and maintained at
394	<http://www.iana.org/assignments/http-parameters>.
395
396
397	Section 5.1.2., paragraph 1:
398	OLD:
399
400	The initial HTTP Range Unit Registry shall contain the registrations
401	below:
402
403	NEW:
404
405	The initial "HTTP Range Unit Registry" contains the registrations
406	below:
407
408
409	Section 5.2., paragraph 1:
410	OLD:
411
412	The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located
413	at <http://www.iana.org/assignments/http-status-codes> has been
414	updated with the registrations below:
415
416	NEW:
417
418	The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located
419	at <http://www.iana.org/assignments/http-status-codes> has been
420	updated to include the registrations below:
421
422
423	Section 5.3., paragraph 1:
424	OLD:
425
426	HTTP header fields are registered within the "Message Headers"
427	registry maintained at
428	<http://www.iana.org/assignments/message-headers/>.
429
430	NEW:
431
432	HTTP header fields are registered within the "Message Headers"
433	registry maintained at
434	<http://www.iana.org/assignments/message-headers>.
435
436
437	Section 5.3., paragraph 2:
438	OLD:
439
440	This document defines the following HTTP header fields, so the
441	"Permanent Message Header Field Names" registry has been updated
442	accordingly (see [BCP90]).
443
444	NEW:
445
446	This document defines the following HTTP header fields; their
447	associated registry entries have been updated according to the
448	permanent registrations below (see [BCP90]):
449
450
451	Section 5.4., paragraph 2:
452	OLD:
453
454	This document serves as the specification for the Internet media type
455	"multipart/byteranges". The following is to be registered with IANA.
456
457	NEW:
458
459	This document serves as the specification for the Internet media type
460	"multipart/byteranges". The following has been registered with IANA.
461
462
463	Section 5.4.1., paragraph 16:
464	OLD:
465
466	Person and email address to contact for further information: See
467	Authors' Addresses Section.
468
469	NEW:
470
471	Person and email address to contact for further information:
472	See Authors' Addresses section of RFC 7233.
473
474
475	Section 5.4.1., paragraph 19:
476	OLD:
477
478	Author: See Authors' Addresses Section.
479
480	NEW:
481
482	Author: See Authors Section.
483
484
485	Section 6., paragraph 2:
486	OLD:
487
488	6.1. Denial of Service Attacks using Range
489
490	NEW:
491
492	6.1. Denial-of-Service Attacks Using Range
493
494
495	Section 8.1., paragraph 4:
496	OLD:
497
498	[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
499	Protocol (HTTP/1.1): Message Syntax and Routing",
500	draft-ietf-httpbis-p1-messaging-latest (work in progress),
501	May 2014.
502
503	NEW:
504
505	[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
506	Protocol (HTTP/1.1): Message Syntax and Routing",
507	RFC 7230, May 2014.
508
509
510	Section 8.1., paragraph 5:
511	OLD:
512
513	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
514	Protocol (HTTP/1.1): Semantics and Content",
515	draft-ietf-httpbis-p2-semantics-latest (work in progress),
516	May 2014.
517
518	NEW:
519
520	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
521	Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
522	May 2014.
523
524
525	Section 8.1., paragraph 6:
526	OLD:
527
528	[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
529	Protocol (HTTP/1.1): Conditional Requests",
530	draft-ietf-httpbis-p4-conditional-latest (work in
531	progress), May 2014.
532
533	NEW:
534
535	[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
536	Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
537	May 2014.
538
539
540	Section 8.1., paragraph 7:
541	OLD:
542
543	[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
544	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
545	draft-ietf-httpbis-p6-cache-latest (work in progress),
546	May 2014.
547
548	NEW:
549
550	[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
551	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
552	RFC 7234, May 2014.
553
554
555	Section 2., paragraph 1:
556	OLD:
557
558	3. A number of clients and servers were coded to an early draft of
559	the byteranges specification that used a media type of multipart/
560	x-byteranges, which is almost (but not quite) compatible with
561	this type.
562
563	NEW:
564
565	3. A number of clients and servers were coded to an early draft
566	version of the byteranges specification that used a media type of
567	multipart/x-byteranges, which is almost (but not quite)
568	compatible with this type.
569
570
571	Appendix B., paragraph 1:
572	OLD:
573
574	Servers are given more leeway in how they respond to a range request,
575	in order to mitigate abuse by malicious (or just greedy) clients.
576	(Section 3.1)
577
578	NEW:
579
580	Servers are given more leeway in how they respond to a range request,
581	in order to mitigate abuse by malicious (or just greedy) clients
582	(Section 3.1).
583
584
585	Appendix B., paragraph 2:
586	OLD:
587
588	A weak validator cannot be used in a 206 response. (Section 4.1)
589
590	NEW:
591
592	A weak validator cannot be used in a 206 response (Section 4.1).
593
594
595	Appendix B., paragraph 3:
596	OLD:
597
598	The Content-Range header field only has meaning when the status code
599	explicitly defines its use. (Section 4.2)
600
601	NEW:
602
603	The Content-Range header field only has meaning when the status code
604	explicitly defines its use (Section 4.2).
605
606
607	Appendix B., paragraph 4:
608	OLD:
609
610	This specification introduces a Range Unit Registry. (Section 5.1)
611
612	NEW:
613
614	This specification introduces a the "HTTP Range Unit Registry"
615	(Section 5.1).
616
617
618	Appendix B., paragraph 5:
619	OLD:
620
621	multipart/byteranges can consist of a single part. (Appendix A)
622
623	NEW:
624
625	multipart/byteranges can consist of a single part (Appendix A).
626
627
628	Appendix C., paragraph 4:
629	OLD:
630
631	OWS = <OWS, see [RFC7230], Section 3.2.3>
632	token = <token, see [RFC7230], Section 3.2.6>
633
634	NEW:
635
636	OWS = <OWS, defined in [RFC7230], Section 3.2.3>
637	token = <token, defined in [RFC7230], Section 3.2.6>
638
639
640	Appendix C., paragraph 6:
641	OLD:
642
643	HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
644	entity-tag = <entity-tag, see [RFC7232], Section 2.3>
645
646	NEW:
647
648	HTTP-date = <HTTP-date, defined in [RFC7231], Section 7.1.1.1>
649	entity-tag = <entity-tag, defined in [RFC7232], Section 2.3>
650
651
652	Section 1.2, paragraph 3:
653	OLD:
654
655	HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
656
657	NEW:
658
659	HTTP-date = <HTTP-date, defined in [RFC7231], Section 7.1.1.1>
660
661
662	Section 1.2, paragraph 5:
663	OLD:
664
665	OWS = <OWS, see [RFC7230], Section 3.2.3>
666
667	NEW:
668
669	OWS = <OWS, defined in [RFC7230], Section 3.2.3>
670
671
672	Section 1.2, paragraph 10:
673	OLD:
674
675	entity-tag = <entity-tag, see [RFC7232], Section 2.3>
676
677	NEW:
678
679	entity-tag = <entity-tag, defined in [RFC7232], Section 2.3>
680
681
682	Section 1.2, paragraph 16:
683	OLD:
684
685	token = <token, see [RFC7230], Section 3.2.6>
686
687	NEW:
688
689	token = <token, defined in [RFC7230], Section 3.2.6>
690
691
692	Section 1.2, paragraph 19:
693	OLD:
694
695	2
696	206 Partial Content (status code) 10
697
698	NEW:
699
700	2
701	206 Partial Content (status code) 9
702
703
704	Section 1.2, paragraph 20:
705	OLD:
706
707	4
708	416 Range Not Satisfiable (status code) 15
709
710	NEW:
711
712	4
713	416 Range Not Satisfiable (status code) 14
714
715
716	Section 1.2, paragraph 21:
717	OLD:
718
719	A
720	Accept-Ranges header field 7
721
722	NEW:
723
724	A
725	Accept-Ranges header field 6
726
727
728	Section 1.2, paragraph 22:
729	OLD:
730
731	C
732	Content-Range header field 12
733
734	NEW:
735
736	C
737	Content-Range header field 11
738
739
740	Section 1.2, paragraph 23:
741	OLD:
742
743	G
744	Grammar
745	Accept-Ranges 7
746	acceptable-ranges 7
747	byte-content-range 12
748	byte-range 12
749	byte-range-resp 12
750	byte-range-set 5
751	byte-range-spec 5
752	byte-ranges-specifier 5
753	bytes-unit 5
754	complete-length 12
755	Content-Range 12
756	first-byte-pos 5
757	If-Range 9
758	last-byte-pos 5
759	other-content-range 12
760	other-range-resp 12
761	other-range-unit 5, 7
762	Range 7
763	range-unit 5
764	ranges-specifier 5
765	suffix-byte-range-spec 6
766	suffix-length 6
767	unsatisfied-range 12
768
769	NEW:
770
771	G
772	Grammar
773	Accept-Ranges 6
774	acceptable-ranges 6
775	byte-content-range 11
776	byte-range 11
777	byte-range-resp 11
778	byte-range-set 4
779	byte-range-spec 4
780	byte-ranges-specifier 4
781	bytes-unit 4
782	complete-length 11
783	Content-Range 11
784	first-byte-pos 4
785	If-Range 8
786	last-byte-pos 4
787	other-content-range 11
788	other-range-resp 11
789	other-range-unit 4, 6
790	Range 6
791	range-unit 4
792	ranges-specifier 4
793	suffix-byte-range-spec 5
794	suffix-length 5
795	unsatisfied-range 11
796
797
798	Section 1.2, paragraph 24:
799	OLD:
800
801	I
802	If-Range header field 9
803
804	NEW:
805
806	I
807	If-Range header field 8
808
809
810	Section 1.2, paragraph 25:
811	OLD:
812
813	M
814	Media Type
815	multipart/byteranges 17, 20
816	multipart/x-byteranges 20
817	multipart/byteranges Media Type 17, 20
818	multipart/x-byteranges Media Type 20
819
820	NEW:
821
822	M
823	Media Type
824	multipart/byteranges 16, 19
825	multipart/x-byteranges 19
826	multipart/byteranges Media Type 16, 19
827	multipart/x-byteranges Media Type 19
828
829
830	Section 1.2, paragraph 26:
831	OLD:
832
833	R
834	Range header field 7
835
836	NEW:
837
838	R
839	Range header field 6
840

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

Download in other formats: