-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathrfc7231.xml
executable file
·6265 lines (6004 loc) · 284 KB
/
rfc7231.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
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
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt'?>
<!DOCTYPE rfc [
<!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
<!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>">
<!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>">
<!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>">
<!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>">
<!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>">
<!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>">
<!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>">
<!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
<!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
<!ENTITY mdash "—">
<!ENTITY Note "<x:h xmlns:x='http://purl.org/net/xml2rfc/ext'>Note:</x:h>">
<!ENTITY architecture "<xref target='RFC7230' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY conformance "<xref target='RFC7230' x:rel='#conformance' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY notation "<xref target='RFC7230' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY acks "<xref target='RFC7230' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY messaging "<xref target='RFC7230' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY conditional "<xref target='RFC7232' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY range "<xref target='RFC7233' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY caching "<xref target='RFC7234' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY auth "<xref target='RFC7235' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY content-negotiation "<xref target='content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY reactive-negotiation "<xref target='reactive.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY abnf-extension "<xref target='RFC7230' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY whitespace "<xref target='RFC7230' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY field-components "<xref target='RFC7230' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY field-parsing "<xref target='RFC7230' x:rel='#field.parsing' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY uri "<xref target='RFC7230' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY effective-request-uri "<xref target='RFC7230' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY intermediaries "<xref target='RFC7230' x:rel='#intermediaries' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY transformations "<xref target='RFC7230' x:rel='#message.transformations' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY chunked-encoding "<xref target='RFC7230' x:rel='#chunked.encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY http-url "<xref target='RFC7230' x:rel='#http-url' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY http-version "<xref target='RFC7230' x:rel='#http.version' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY request-target "<xref target='RFC7230' x:rel='#request-target' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-accept "<xref target='header.accept' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-accept-charset "<xref target='header.accept-charset' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-accept-encoding "<xref target='header.accept-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-accept-language "<xref target='header.accept-language' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-accept-ranges "<xref target='RFC7233' x:rel='#header.accept-ranges' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-age "<xref target='RFC7234' x:rel='#header.age' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-authorization "<xref target='RFC7235' x:rel='#header.authorization' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-cache-control "<xref target='RFC7234' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-connection "<xref target='RFC7230' x:rel='#header.connection' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-content-length "<xref target='RFC7230' x:rel='#header.content-length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-content-location "<xref target='header.content-location' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-content-range "<xref target='RFC7233' x:rel='#header.content-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-content-type "<xref target='header.content-type' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-etag "<xref target='RFC7232' x:rel='#header.etag' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-expires "<xref target='RFC7234' x:rel='#header.expires' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-fields "<xref target='RFC7230' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-host "<xref target='RFC7230' x:rel='#header.host' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-if-match "<xref target='RFC7232' x:rel='#header.if-match' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-if-modified-since "<xref target='RFC7232' x:rel='#header.if-modified-since' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-if-none-match "<xref target='RFC7232' x:rel='#header.if-none-match' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-if-range "<xref target='RFC7233' x:rel='#header.if-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-if-unmodified-since "<xref target='RFC7232' x:rel='#header.if-unmodified-since' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-last-modified "<xref target='RFC7232' x:rel='#header.last-modified' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-pragma "<xref target='RFC7234' x:rel='#header.pragma' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-proxy-authenticate "<xref target='RFC7235' x:rel='#header.proxy-authenticate' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-proxy-authorization "<xref target='RFC7235' x:rel='#header.proxy-authorization' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-range "<xref target='RFC7233' x:rel='#header.range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-te "<xref target='RFC7230' x:rel='#header.te' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-trailer "<xref target='RFC7230' x:rel='#header.trailer' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-transfer-encoding "<xref target='RFC7230' x:rel='#header.transfer-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-upgrade "<xref target='RFC7230' x:rel='#header.upgrade' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-user-agent "<xref target='header.user-agent' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-via "<xref target='RFC7230' x:rel='#header.via' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-warning "<xref target='RFC7234' x:rel='#header.warning' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-www-authenticate "<xref target='RFC7235' x:rel='#header.www-authenticate' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY media-type "<xref target='media.type' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY message-body "<xref target='RFC7230' x:rel='#message.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY media-type-message-http "<xref target='RFC7230' x:rel='#internet.media.type.message.http' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY persistent-tear-down "<xref target='RFC7230' x:rel='#persistent.tear-down' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY status-206 "<xref target='RFC7233' x:rel='#status.206' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY status-304 "<xref target='RFC7232' x:rel='#status.304' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY status-401 "<xref target='RFC7235' x:rel='#status.401' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY status-407 "<xref target='RFC7235' x:rel='#status.407' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY status-412 "<xref target='RFC7232' x:rel='#status.412' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY status-416 "<xref target='RFC7233' x:rel='#status.416' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY p1-security-considerations "<xref target='RFC7230' x:rel='#security.considerations' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY p4-status-codes "<xref target='RFC7232' x:rel='#status.code.definitions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY p5-status-codes "<xref target='RFC7233' x:rel='#range.response' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY p7-status-codes "<xref target='RFC7235' x:rel='#status.code.definitions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY p6-heuristic "<xref target='RFC7234' x:rel='#heuristic.freshness' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY p6-explicit "<xref target='RFC7234' x:rel='#calculating.freshness.lifetime' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY p6-invalid "<xref target='RFC7234' x:rel='#invalidation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY p6-head "<xref target='RFC7234' x:rel='#head.effects' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY qvalue "<xref target='quality.values'/>">
<!ENTITY architecture "<xref target='RFC7230' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY notation "<xref target='RFC7230' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY abnf-extension "<xref target='RFC7230' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY acks "<xref target='RFC7230' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY whitespace "<xref target='RFC7230' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY field-components "<xref target='RFC7230' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY caching-neg-resp "<xref target='RFC7234' x:rel='#caching.negotiated.responses' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY message-body "<xref target='RFC7230' x:rel='#message.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY multipart-byteranges "<xref target='RFC7233' x:rel='#internet.media.type.multipart.byteranges' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY evaluate-conditional "<xref target='RFC7232' x:rel='#evaluation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY http-date "<xref target='http.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY uri "<xref target='RFC7230' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY effective-request-uri "<xref target='RFC7230' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY compression-codings "<xref target='RFC7230' x:rel='#compression.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY transfer-codings "<xref target='RFC7230' x:rel='#transfer.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY compress-coding "<xref target='RFC7230' x:rel='#compress.coding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY deflate-coding "<xref target='RFC7230' x:rel='#deflate.coding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY gzip-coding "<xref target='RFC7230' x:rel='#gzip.coding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no" ?>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-references-in-index="yes" ?>
<rfc obsoletes="2616" updates="2817" category="std" x:maturity-level="proposed"
ipr="pre5378Trust200902" number="7231" consensus="yes"
xmlns:x='http://purl.org/net/xml2rfc/ext'
xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<x:link rel="prev" basename="rfc7230"/>
<x:link rel="next" basename="rfc7232"/>
<!--<x:feedback template="mailto:[email protected]?subject={docname},%20%22{section}%22&body=<{ref}>:"/>-->
<front>
<title abbrev="HTTP/1.1 Semantics and Content">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
<author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
<organization abbrev="Adobe">Adobe Systems Incorporated</organization>
<address>
<postal>
<street>345 Park Ave</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>USA</country>
</postal>
<uri>http://roy.gbiv.com/</uri>
</address>
</author>
<author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
<organization abbrev="greenbytes">greenbytes GmbH</organization>
<address>
<postal>
<street>Hafenweg 16</street>
<city>Muenster</city><region>NW</region><code>48155</code>
<country>Germany</country>
</postal>
<uri>http://greenbytes.de/tech/webdav/</uri>
</address>
</author>
<date month="June" year="2014"/>
<area>Applications</area>
<workgroup>HTTPbis</workgroup>
<keyword>Hypertext Transfer Protocol</keyword>
<keyword>HTTP</keyword>
<keyword>HTTP semantics</keyword>
<keyword>HTTP payload</keyword>
<keyword>HTTP content</keyword>
<keyword>HTTP method</keyword>
<keyword>HTTP status code</keyword>
<abstract>
<t>
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for
distributed, collaborative, hypertext information systems. This document
defines the semantics of HTTP/1.1 messages, as expressed by request
methods, request header fields, response status codes, and response header
fields, along with the payload of messages (metadata and body content) and
mechanisms for content negotiation.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="introduction">
<t>
Each Hypertext Transfer Protocol (HTTP) message is either a request or a
response. A server listens on a connection for a request, parses each
message received, interprets the message semantics in relation to the
identified request target, and responds to that request with one or more
response messages. A client constructs request messages to communicate
specific intentions, examines received responses to see if the
intentions were carried out, and determines how to interpret the results.
This document defines HTTP/1.1 request and response semantics in terms of
the architecture defined in <xref target="RFC7230"/>.
</t>
<t>
HTTP provides a uniform interface for interacting with a resource
(<xref target="resources"/>), regardless of its type, nature, or
implementation, via the manipulation and transfer of representations
(<xref target="representations"/>).
</t>
<t>
HTTP semantics include the intentions defined by each request method
(<xref target="methods"/>), extensions to those semantics that might be
described in request header fields (<xref target="request.header.fields"/>),
the meaning of status codes to indicate a machine-readable response
(<xref target="status.codes"/>), and the meaning of other control data
and resource metadata that might be given in response header fields
(<xref target="response.header.fields"/>).
</t>
<t><iref item="content negotiation"/>
This document also defines representation metadata that describe how a
payload is intended to be interpreted by a recipient, the request header
fields that might influence content selection, and the various selection
algorithms that are collectively referred to as
"<x:dfn>content negotiation</x:dfn>" (<xref target="content.negotiation"/>).
</t>
<section title="Conformance and Error Handling" anchor="conformance">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"/>.
</t>
<t>
Conformance criteria and considerations regarding error handling
are defined in &conformance;.
</t>
</section>
<section title="Syntax Notation" anchor="notation">
<t>
This specification uses the Augmented Backus-Naur Form (ABNF) notation of
<xref target="RFC5234"/> with a list extension, defined in
&abnf-extension;, that allows for compact definition of
comma-separated lists using a '#' operator (similar to how the '*' operator
indicates repetition).
<xref target="imported.abnf"/> describes rules imported from
other documents.
<xref target="collected.abnf"/> shows the collected grammar with all list
operators expanded to standard ABNF notation.
</t>
<t>
This specification uses the terms
"character",
"character encoding scheme",
"charset", and
"protocol element"
as they are defined in <xref target="RFC6365"/>.
</t>
</section>
</section>
<section title="Resources" anchor="resources">
<x:anchor-alias value="target resource"/>
<t>
The target of an HTTP request is called a "<x:dfn>resource</x:dfn>".
HTTP does not limit the nature of a resource; it merely
defines an interface that might be used to interact with resources.
Each resource is identified by a Uniform Resource Identifier (URI), as
described in &uri;.
</t>
<t>
When a client constructs an HTTP/1.1 request message, it sends the
<x:ref>target URI</x:ref> in one of various forms, as defined in
(&request-target;). When a request is received, the server reconstructs
an <x:ref>effective request URI</x:ref> for the target resource
(&effective-request-uri;).
</t>
<t>
One design goal of HTTP is to separate resource identification from
request semantics, which is made possible by vesting the request
semantics in the request method (<xref target="methods"/>) and a few
request-modifying header fields (<xref target="request.header.fields"/>).
If there is a conflict between the method semantics and any semantic
implied by the URI itself, as described in <xref target="safe.methods"/>,
the method semantics take precedence.
</t>
</section>
<section title="Representations" anchor="representations">
<iref primary="true" item="representation"/>
<iref primary="true" item="selected representation"/>
<x:anchor-alias value="representation"/>
<x:anchor-alias value="selected representation"/>
<t>
Considering that a resource could be anything, and that the uniform
interface provided by HTTP is similar to a window through which one can
observe and act upon such a thing only through the communication of
messages to some independent actor on the other side, an abstraction is
needed to represent ("take the place of") the current or desired state of
that thing in our communications. That abstraction is called a
representation <xref target="REST"/>.
</t>
<t>
For the purposes of HTTP, a "<x:dfn>representation</x:dfn>" is information
that is intended to reflect a past, current, or desired state of a given
resource, in a format that can be readily communicated via the protocol,
and that consists of a set of representation metadata and a potentially
unbounded stream of representation data.
</t>
<t>
An origin server might be provided with, or be capable of generating, multiple
representations that are each intended to reflect the current state of a
<x:ref>target resource</x:ref>. In such cases, some algorithm is used by
the origin server to select one of those representations as most applicable
to a given request, usually based on <x:ref>content negotiation</x:ref>.
This "<x:dfn>selected representation</x:dfn>" is used to provide the data
and metadata for evaluating conditional requests <xref target="RFC7232"/> and
constructing the payload for <x:ref>200 (OK)</x:ref> and
<x:ref>304 (Not Modified)</x:ref> responses to GET (<xref target="GET"/>).
</t>
<section title="Representation Metadata" anchor="representation.metadata">
<x:anchor-alias value="representation-header"/>
<t>
Representation header fields provide metadata about the representation.
When a message includes a payload body, the representation header fields
describe how to interpret the representation data enclosed in the payload
body. In a response to a HEAD request, the representation header fields
describe the representation data that would have been enclosed in the
payload body if the same request had been a GET.
</t>
<t>
The following header fields convey representation metadata:
</t>
<texttable align="left">
<ttcol>Header Field Name</ttcol>
<ttcol>Defined in...</ttcol>
<c>Content-Type</c> <c><xref target="header.content-type"/></c>
<c>Content-Encoding</c> <c><xref target="header.content-encoding"/></c>
<c>Content-Language</c> <c><xref target="header.content-language"/></c>
<c>Content-Location</c> <c><xref target="header.content-location"/></c>
</texttable>
<section title="Processing Representation Data" anchor="data.type">
<section title="Media Type" anchor="media.type">
<x:anchor-alias value="media-type"/>
<x:anchor-alias value="type"/>
<x:anchor-alias value="subtype"/>
<t>
HTTP uses Internet media types <xref target="RFC2046"/> in the
<x:ref>Content-Type</x:ref> (<xref target="header.content-type"/>)
and <x:ref>Accept</x:ref> (<xref target="header.accept"/>) header fields in
order to provide open and extensible data typing and type negotiation.
Media types define both a data format and various processing models:
how to process that data in accordance with each context in which it
is received.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="media-type"/><iref primary="true" item="Grammar" subitem="type"/><iref primary="true" item="Grammar" subitem="subtype"/>
<x:ref>media-type</x:ref> = <x:ref>type</x:ref> "/" <x:ref>subtype</x:ref> *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>parameter</x:ref> )
<x:ref>type</x:ref> = <x:ref>token</x:ref>
<x:ref>subtype</x:ref> = <x:ref>token</x:ref>
</artwork></figure>
<t anchor="rule.parameter">
<x:anchor-alias value="parameter"/>
The type/subtype &MAY; be followed by parameters in the form of
name=value pairs.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="parameter"/>
<x:ref>parameter</x:ref> = <x:ref>token</x:ref> "=" ( <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref> )
</artwork></figure>
<t>
The type, subtype, and parameter name tokens are case-insensitive.
Parameter values might or might not be case-sensitive, depending on the
semantics of the parameter name. The presence or absence of a parameter might
be significant to the processing of a media-type, depending on its
definition within the media type registry.
</t>
<t>
A parameter value that matches the <x:ref>token</x:ref> production can be
transmitted either as a token or within a quoted-string. The quoted and
unquoted values are equivalent. For example, the following examples are
all equivalent, but the first is preferred for consistency:
</t>
<figure><artwork type="example">
text/html;charset=utf-8
text/html;charset=UTF-8
Text/HTML;Charset="utf-8"
text/html; charset="utf-8"
</artwork></figure>
<t>
Internet media types ought to be registered with IANA according to the
procedures defined in <xref target="BCP13"/>.
</t>
<x:note>
<t>
&Note; Unlike some similar constructs in other header fields, media type
parameters do not allow whitespace (even "bad" whitespace) around the "="
character.
</t>
</x:note>
</section>
<section title="Charset" anchor="charset">
<x:anchor-alias value="rule.charset"/>
<t>
HTTP uses <x:dfn>charset</x:dfn> names to indicate or negotiate the
character encoding scheme of a textual representation
<xref target="RFC6365"/>.
A charset is identified by a case-insensitive token.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="charset"/>
<x:ref>charset</x:ref> = <x:ref>token</x:ref>
</artwork></figure>
<t>
Charset names ought to be registered in the IANA "Character Sets" registry
(<eref target="http://www.iana.org/assignments/character-sets"/>)
according to the procedures defined in <xref target="RFC2978"/>.
</t>
</section>
<section title="Canonicalization and Text Defaults" anchor="canonicalization.and.text.defaults">
<t>
Internet media types are registered with a canonical form in order to be
interoperable among systems with varying native encoding formats.
Representations selected or transferred via HTTP ought to be in canonical
form, for many of the same reasons described by the Multipurpose Internet
Mail Extensions (MIME) <xref target="RFC2045"/>.
However, the performance characteristics of email deployments (i.e., store
and forward messages to peers) are significantly different from those
common to HTTP and the Web (server-based information services).
Furthermore, MIME's constraints for the sake of compatibility with older
mail transfer protocols do not apply to HTTP
(see <xref target="differences.between.http.and.mime"/>).
</t>
<t>
MIME's canonical form requires that media subtypes of the "text"
type use CRLF as the text line break. HTTP allows the
transfer of text media with plain CR or LF alone representing a line
break, when such line breaks are consistent for an entire representation.
An HTTP sender &MAY; generate, and a recipient &MUST; be able to parse,
line breaks in text media that consist of CRLF, bare CR, or bare LF.
In addition, text media in HTTP is not limited to charsets that
use octets 13 and 10 for CR and LF, respectively.
This flexibility regarding line breaks applies only to text within a
representation that has been assigned a "text" media type; it does not
apply to "multipart" types or HTTP elements outside the payload body
(e.g., header fields).
</t>
<t>
If a representation is encoded with a content-coding, the underlying
data ought to be in a form defined above prior to being encoded.
</t>
</section>
<section title="Multipart Types" anchor="multipart.types">
<t>
MIME provides for a number of "multipart" types — encapsulations of
one or more representations within a single message body. All multipart
types share a common syntax, as defined in <xref target="RFC2046" x:sec="5.1.1" x:fmt="of"/>,
and include a boundary parameter as part of the media type
value. The message body is itself a protocol element; a sender &MUST;
generate only CRLF to represent line breaks between body parts.
</t>
<t>
HTTP message framing does not use the multipart boundary as an indicator
of message body length, though it might be used by implementations that
generate or process the payload. For example, the "multipart/form-data"
type is often used for carrying form data in a request, as described in
<xref target="RFC2388"/>, and the "multipart/byteranges" type is defined
by this specification for use in some <x:ref>206 (Partial Content)</x:ref>
responses <xref target="RFC7233"/>.
</t>
</section>
<section title="Content-Type" anchor="header.content-type">
<iref primary="true" item="Content-Type header field" x:for-anchor=""/>
<x:anchor-alias value="Content-Type"/>
<t>
The "Content-Type" header field indicates the media type of the
associated representation: either the representation enclosed in
the message payload or the <x:ref>selected representation</x:ref>, as determined by the
message semantics. The indicated media type defines both the data format
and how that data is intended to be processed by a recipient, within the
scope of the received message semantics, after any content codings
indicated by <x:ref>Content-Encoding</x:ref> are decoded.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Type"/>
<x:ref>Content-Type</x:ref> = <x:ref>media-type</x:ref>
</artwork></figure>
<t>
Media types are defined in <xref target="media.type"/>. An example of the
field is
</t>
<figure><artwork type="example">
Content-Type: text/html; charset=ISO-8859-4
</artwork></figure>
<t>
A sender that generates a message containing a payload body &SHOULD;
generate a Content-Type header field in that message unless the intended
media type of the enclosed representation is unknown to the sender.
If a Content-Type header field is not present, the recipient &MAY; either
assume a media type of
"application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
or examine the data to determine its type.
</t>
<t>
In practice, resource owners do not always properly configure their origin
server to provide the correct Content-Type for a given representation,
with the result that some clients will examine a payload's content
and override the specified type.
Clients that do so risk drawing incorrect conclusions, which might expose
additional security risks (e.g., "privilege escalation"). Furthermore,
it is impossible to determine the sender's intent by examining the data
format: many data formats match multiple media types that differ only in
processing semantics. Implementers are encouraged to provide a means of
disabling such "content sniffing" when it is used.
</t>
</section>
</section>
<section title="Encoding for Compression or Integrity" anchor="data.encoding">
<section title="Content Codings" anchor="content.codings">
<iref primary="true" item="content coding"/>
<iref primary="true" item="compress (content coding)"/>
<iref primary="true" item="x-compress (content coding)"/>
<iref primary="true" item="deflate (content coding)"/>
<iref primary="true" item="gzip (content coding)"/>
<iref primary="true" item="x-gzip (content coding)"/>
<x:anchor-alias value="content-coding"/>
<t>
Content coding values indicate an encoding transformation that has
been or can be applied to a representation. Content codings are primarily
used to allow a representation to be compressed or otherwise usefully
transformed without losing the identity of its underlying media type
and without loss of information. Frequently, the representation is stored
in coded form, transmitted directly, and only decoded by the final recipient.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="content-coding"/>
<x:ref>content-coding</x:ref> = <x:ref>token</x:ref>
</artwork></figure>
<t>
All content-coding values are case-insensitive and ought to be registered
within the "HTTP Content Coding Registry", as defined in
<xref target="content.coding.registry"/>. They are used in the
<x:ref>Accept-Encoding</x:ref> (<xref target="header.accept-encoding"/>)
and <x:ref>Content-Encoding</x:ref> (<xref target="header.content-encoding"/>)
header fields.
</t>
<t>
The following content-coding values are defined by this specification:
<list>
<t>compress (and x-compress): See &compress-coding;.</t>
<t>deflate: See &deflate-coding;.</t>
<t>gzip (and x-gzip): See &gzip-coding;.</t>
</list>
</t>
</section>
<section title="Content-Encoding" anchor="header.content-encoding">
<iref primary="true" item="Content-Encoding header field" x:for-anchor=""/>
<x:anchor-alias value="Content-Encoding"/>
<t>
The "Content-Encoding" header field indicates what content codings
have been applied to the representation, beyond those inherent in the media
type, and thus what decoding mechanisms have to be applied in order to
obtain data in the media type referenced by the <x:ref>Content-Type</x:ref>
header field.
Content-Encoding is primarily used to allow a representation's data to be
compressed without losing the identity of its underlying media type.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/>
<x:ref>Content-Encoding</x:ref> = 1#<x:ref>content-coding</x:ref>
</artwork></figure>
<t>
An example of its use is
</t>
<figure><artwork type="example">
Content-Encoding: gzip
</artwork></figure>
<t>
If one or more encodings have been applied to a representation, the sender
that applied the encodings &MUST; generate a Content-Encoding header field
that lists the content codings in the order in which they were applied.
Additional information about the encoding parameters can be provided
by other header fields not defined by this specification.
</t>
<t>
Unlike Transfer-Encoding (&header-transfer-encoding;), the codings listed
in Content-Encoding are a characteristic of the representation; the
representation is defined in terms of the coded form, and all other
metadata about the representation is about the coded form unless otherwise
noted in the metadata definition. Typically, the representation is only
decoded just prior to rendering or analogous usage.
</t>
<t>
If the media type includes an inherent encoding, such as a data format
that is always compressed, then that encoding would not be restated in
Content-Encoding even if it happens to be the same algorithm as one
of the content codings. Such a content coding would only be listed if,
for some bizarre reason, it is applied a second time to form the
representation. Likewise, an origin server might choose to publish the
same data as multiple representations that differ only in whether
the coding is defined as part of <x:ref>Content-Type</x:ref> or
Content-Encoding, since some user agents will behave differently in their
handling of each response (e.g., open a "Save as ..." dialog instead of
automatic decompression and rendering of content).
</t>
<t>
An origin server &MAY; respond with a status code of
<x:ref>415 (Unsupported Media Type)</x:ref> if a representation in the
request message has a content coding that is not acceptable.
</t>
</section>
</section>
<section title="Audience Language" anchor="audience.language">
<section title="Language Tags" anchor="language.tags">
<x:anchor-alias value="language-tag"/>
<t>
A language tag, as defined in <xref target="RFC5646"/>, identifies a
natural language spoken, written, or otherwise conveyed by human beings for
communication of information to other human beings. Computer languages are
explicitly excluded.
</t>
<t>
HTTP uses language tags within the <x:ref>Accept-Language</x:ref> and
<x:ref>Content-Language</x:ref> header fields.
<x:ref>Accept-Language</x:ref> uses the broader language-range production
defined in <xref target="header.accept-language"/>, whereas
<x:ref>Content-Language</x:ref> uses the language-tag production defined
below.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="language-tag"/>
<x:ref>language-tag</x:ref> = <Language-Tag, see <xref target="RFC5646" x:sec="2.1"/>>
</artwork></figure>
<t>
A language tag is a sequence of one or more case-insensitive subtags, each
separated by a hyphen character ("-", %x2D). In most cases, a language tag
consists of a primary language subtag that identifies a broad family of
related languages (e.g., "en" = English), which is optionally followed by a
series of subtags that refine or narrow that language's range (e.g.,
"en-CA" = the variety of English as communicated in Canada).
Whitespace is not allowed within a language tag.
Example tags include:
</t>
<figure><artwork type="example">
fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
</artwork></figure>
<t>
See <xref target="RFC5646"/> for further information.
</t>
</section>
<section title="Content-Language" anchor="header.content-language">
<iref primary="true" item="Content-Language header field" x:for-anchor=""/>
<x:anchor-alias value="Content-Language"/>
<t>
The "Content-Language" header field describes the natural
language(s) of the intended audience for the representation. Note that this might
not be equivalent to all the languages used within the representation.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/>
<x:ref>Content-Language</x:ref> = 1#<x:ref>language-tag</x:ref>
</artwork></figure>
<t>
Language tags are defined in <xref target="language.tags"/>. The primary purpose of
Content-Language is to allow a user to identify and differentiate
representations according to the users' own preferred language. Thus, if the
content is intended only for a Danish-literate audience, the
appropriate field is
</t>
<figure><artwork type="example">
Content-Language: da
</artwork></figure>
<t>
If no Content-Language is specified, the default is that the content
is intended for all language audiences. This might mean that the
sender does not consider it to be specific to any natural language,
or that the sender does not know for which language it is intended.
</t>
<t>
Multiple languages &MAY; be listed for content that is intended for
multiple audiences. For example, a rendition of the "Treaty of
Waitangi", presented simultaneously in the original Maori and English
versions, would call for
</t>
<figure><artwork type="example">
Content-Language: mi, en
</artwork></figure>
<t>
However, just because multiple languages are present within a representation
does not mean that it is intended for multiple linguistic audiences.
An example would be a beginner's language primer, such as "A First
Lesson in Latin", which is clearly intended to be used by an
English-literate audience. In this case, the Content-Language would
properly only include "en".
</t>
<t>
Content-Language &MAY; be applied to any media type — it is not
limited to textual documents.
</t>
</section>
</section>
<section title="Identification" anchor="identification">
<section title="Identifying a Representation" anchor="identifying.payload">
<t>
When a complete or partial representation is transferred in a message
payload, it is often desirable for the sender to supply, or the recipient
to determine, an identifier for a resource corresponding to that
representation.
</t>
<t>
For a request message:
<list style="symbols">
<t>If the request has a <x:ref>Content-Location</x:ref> header field,
then the sender asserts that the payload is a representation of the
resource identified by the Content-Location field-value. However,
such an assertion cannot be trusted unless it can be verified by
other means (not defined by this specification). The information
might still be useful for revision history links.</t>
<t>Otherwise, the payload is unidentified.</t>
</list>
</t>
<t>
For a response message, the following rules are applied in order until a
match is found:
<list style="numbers">
<t>If the request method is GET or HEAD and the response status code is
<x:ref>200 (OK)</x:ref>,
<x:ref>204 (No Content)</x:ref>,
<x:ref>206 (Partial Content)</x:ref>, or
<x:ref>304 (Not Modified)</x:ref>,
the payload is a representation of the resource identified by the
effective request URI (&effective-request-uri;).</t>
<t>If the request method is GET or HEAD and the response status code is
<x:ref>203 (Non-Authoritative Information)</x:ref>, the payload is
a potentially modified or enhanced representation of the
<x:ref>target resource</x:ref> as provided by an intermediary.</t>
<t>If the response has a <x:ref>Content-Location</x:ref> header field
and its field-value is a reference to the same URI as the effective
request URI, the payload is a representation of the resource
identified by the effective request URI.</t>
<t>If the response has a <x:ref>Content-Location</x:ref> header field
and its field-value is a reference to a URI different from the
effective request URI, then the sender asserts that the payload is a
representation of the resource identified by the Content-Location
field-value. However, such an assertion cannot be trusted unless
it can be verified by other means (not defined by this specification).</t>
<t>Otherwise, the payload is unidentified.</t>
</list>
</t>
</section>
<section title="Content-Location" anchor="header.content-location">
<iref primary="true" item="Content-Location header field" x:for-anchor=""/>
<x:anchor-alias value="Content-Location"/>
<t>
The "Content-Location" header field references a URI that can be used
as an identifier for a specific resource corresponding to the
representation in this message's payload.
In other words, if one were to perform a GET request on this URI at the time
of this message's generation, then a <x:ref>200 (OK)</x:ref> response would
contain the same representation that is enclosed as payload in this message.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/>
<x:ref>Content-Location</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref>
</artwork></figure>
<t>
The Content-Location value is not a replacement for the effective
Request URI (&effective-request-uri;). It is representation metadata.
It has the same syntax and semantics as the header field of the same name
defined for MIME body parts in <xref target="RFC2557" x:fmt="of" x:sec="4"/>.
However, its appearance in an HTTP message has some special implications
for HTTP recipients.
</t>
<t>
If Content-Location is included in a <x:ref>2xx (Successful)</x:ref>
response message and its value refers (after conversion to absolute form)
to a URI that is the same as the effective request URI, then
the recipient &MAY; consider the payload to be a current representation of
that resource at the time indicated by the message origination date.
For a GET (<xref target="GET"/>) or HEAD (<xref target="HEAD"/>) request,
this is the same as the default semantics when no Content-Location is
provided by the server.
For a state-changing request like PUT (<xref target="PUT"/>) or
POST (<xref target="POST"/>), it implies that the server's response
contains the new representation of that resource, thereby distinguishing it
from representations that might only report about the action
(e.g., "It worked!").
This allows authoring applications to update their local copies without
the need for a subsequent GET request.
</t>
<t>
If Content-Location is included in a <x:ref>2xx (Successful)</x:ref>
response message and its field-value refers to a URI that differs from the
effective request URI, then the origin server claims that the URI
is an identifier for a different resource corresponding to the enclosed
representation. Such a claim can only be trusted if both identifiers share
the same resource owner, which cannot be programmatically determined via
HTTP.
<list style="symbols">
<t>For a response to a GET or HEAD request, this is an indication that the
effective request URI refers to a resource that is subject to content
negotiation and the Content-Location field-value is a more specific
identifier for the <x:ref>selected representation</x:ref>.</t>
<t>For a <x:ref>201 (Created)</x:ref> response to a state-changing method,
a Content-Location field-value that is identical to the
<x:ref>Location</x:ref> field-value indicates that this payload is a
current representation of the newly created resource.</t>
<t>Otherwise, such a Content-Location indicates that this payload is a
representation reporting on the requested action's status and that the
same report is available (for future access with GET) at the given URI.
For example, a purchase transaction made via a POST request might
include a receipt document as the payload of the <x:ref>200 (OK)</x:ref>
response; the Content-Location field-value provides an identifier for
retrieving a copy of that same receipt in the future.</t>
</list>
</t>
<t>
A user agent that sends Content-Location in a request message is stating
that its value refers to where the user agent originally obtained the
content of the enclosed representation (prior to any modifications made by
that user agent). In other words, the user agent is providing a back link
to the source of the original representation.
</t>
<t>
An origin server that receives a Content-Location field in a request
message &MUST; treat the information as transitory request context rather
than as metadata to be saved verbatim as part of the representation.
An origin server &MAY; use that context to guide in processing the
request or to save it for other uses, such as within source links or
versioning metadata. However, an origin server &MUST-NOT; use such context
information to alter the request semantics.
</t>
<t>
For example, if a client makes a PUT request on a negotiated resource and
the origin server accepts that PUT (without redirection), then the new
state of that resource is expected to be consistent with the one
representation supplied in that PUT; the Content-Location cannot be used as
a form of reverse content selection identifier to update only one of the
negotiated representations. If the user agent had wanted the latter
semantics, it would have applied the PUT directly to the Content-Location
URI.
</t>
</section>
</section>
</section>
<section title="Representation Data" anchor="representation.data">
<x:anchor-alias value="representation-data"/>
<t>
The representation data associated with an HTTP message is
either provided as the payload body of the message or
referred to by the message semantics and the effective request
URI. The representation data is in a format and encoding defined by
the representation metadata header fields.
</t>
<t>
The data type of the representation data is determined via the header fields
<x:ref>Content-Type</x:ref> and <x:ref>Content-Encoding</x:ref>.
These define a two-layer, ordered encoding model:
</t>
<figure><artwork type="example">
representation-data := Content-Encoding( Content-Type( bits ) )
</artwork></figure>
</section>
<section title="Payload Semantics" anchor="payload">
<iref item="payload"/>
<t>
Some HTTP messages transfer a complete or partial representation as the
message "<x:dfn>payload</x:dfn>". In some cases, a payload might contain
only the associated representation's header fields (e.g., responses to
HEAD) or only some part(s) of the representation data
(e.g., the <x:ref>206 (Partial Content)</x:ref> status code).
</t>
<t>
The purpose of a payload in a request is defined by the method semantics.
For example, a representation in the payload of a PUT request
(<xref target="PUT"/>) represents the desired state of the
<x:ref>target resource</x:ref> if the request is successfully applied,
whereas a representation in the payload of a POST request
(<xref target="POST"/>) represents information to be processed by the
target resource.
</t>
<t>
In a response, the payload's purpose is defined by both the request method
and the response status code.
For example, the payload of a <x:ref>200 (OK)</x:ref> response to GET
(<xref target="GET"/>) represents the current state of the
<x:ref>target resource</x:ref>, as observed at the time of the message
origination date (<xref target="header.date"/>), whereas the payload of
the same status code in a response to POST might represent either the
processing result or the new state of the target resource after applying
the processing. Response messages with an error status code usually contain
a payload that represents the error condition, such that it describes the
error state and what next steps are suggested for resolving it.
</t>
<t>
Header fields that specifically describe the payload, rather than the
associated representation, are referred to as "payload header fields".
Payload header fields are defined in other parts of this specification,
due to their impact on message parsing.
</t>
<texttable align="left">
<ttcol>Header Field Name</ttcol>
<ttcol>Defined in...</ttcol>
<c>Content-Length</c> <c>&header-content-length;</c>
<c>Content-Range</c> <c>&header-content-range;</c>
<c>Trailer</c> <c>&header-trailer;</c>
<c>Transfer-Encoding</c> <c>&header-transfer-encoding;</c>
</texttable>
</section>
<section title="Content Negotiation" anchor="content.negotiation">
<x:anchor-alias value="content negotiation"/>
<t>
When responses convey payload information, whether indicating a success or
an error, the origin server often has different ways of representing that
information; for example, in different formats, languages, or encodings.
Likewise, different users or user agents might have differing capabilities,
characteristics, or preferences that could influence which representation,
among those available, would be best to deliver. For this reason, HTTP
provides mechanisms for <x:ref>content negotiation</x:ref>.
</t>
<t>
This specification defines two patterns of content negotiation that can
be made visible within the protocol:
"proactive", where the server selects the representation based
upon the user agent's stated preferences, and "reactive" negotiation,
where the server provides a list of representations for the user agent to
choose from. Other patterns of content negotiation include
"conditional content", where the representation consists of multiple
parts that are selectively rendered based on user agent parameters,
"active content", where the representation contains a script that
makes additional (more specific) requests based on the user agent
characteristics, and "Transparent Content Negotiation"
(<xref target="RFC2295"/>), where content selection is performed by
an intermediary. These patterns are not mutually exclusive, and each has
trade-offs in applicability and practicality.
</t>
<t>
Note that, in all cases, HTTP is not aware of the resource semantics.
The consistency with which an origin server responds to requests, over time
and over the varying dimensions of content negotiation, and thus the
"sameness" of a resource's observed representations over time, is
determined entirely by whatever entity or algorithm selects or generates
those responses. HTTP pays no attention to the man behind the curtain.
</t>
<section title="Proactive Negotiation" anchor="proactive.negotiation">
<x:anchor-alias value="proactive negotiation"/>
<x:anchor-alias value="server-driven negotiation"/>
<t>
When content negotiation preferences are sent by the user agent in a
request to encourage an algorithm located at the server to
select the preferred representation, it is called
<x:dfn>proactive negotiation</x:dfn>
(a.k.a., <x:dfn>server-driven negotiation</x:dfn>). Selection is based on
the available representations for a response (the dimensions over which it
might vary, such as language, content-coding, etc.) compared to various
information supplied in the request, including both the explicit
negotiation fields of <xref target="request.conneg"/> and implicit
characteristics, such as the client's network address or parts of the
<x:ref>User-Agent</x:ref> field.
</t>
<t>
Proactive negotiation is advantageous when the algorithm for
selecting from among the available representations is difficult to
describe to a user agent, or when the server desires to send its
"best guess" to the user agent along with the first response (hoping to
avoid the round trip delay of a subsequent request if the "best
guess" is good enough for the user). In order to improve the server's
guess, a user agent &MAY; send request header fields that describe
its preferences.
</t>
<t>
Proactive negotiation has serious disadvantages:
<list style="symbols">
<t>
It is impossible for the server to accurately determine what
might be "best" for any given user, since that would require
complete knowledge of both the capabilities of the user agent
and the intended use for the response (e.g., does the user want
to view it on screen or print it on paper?);
</t>
<t>
Having the user agent describe its capabilities in every
request can be both very inefficient (given that only a small
percentage of responses have multiple representations) and a
potential risk to the user's privacy;
</t>
<t>
It complicates the implementation of an origin server and the
algorithms for generating responses to a request; and,
</t>
<t>