-
Notifications
You must be signed in to change notification settings - Fork 1
/
rfc7230.xml
executable file
·5595 lines (5405 loc) · 249 KB
/
rfc7230.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 nbsp " ">
<!ENTITY nbhy "‑">
<!ENTITY Note "<x:h xmlns:x='http://purl.org/net/xml2rfc/ext'>Note:</x:h>">
<!ENTITY caching-overview "<xref target='RFC7234' x:rel='#caching.overview' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY cache-incomplete "<xref target='RFC7234' x:rel='#response.cacheability' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY cache-poisoning "<xref target='RFC7234' x:rel='#security.considerations' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY payload "<xref target='RFC7231' x:rel='#payload' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY media-type "<xref target='RFC7231' x:rel='#media.type' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY content-codings "<xref target='RFC7231' x:rel='#content.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY CONNECT "<xref target='RFC7231' x:rel='#CONNECT' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY content.negotiation "<xref target='RFC7231' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY diff-mime "<xref target='RFC7231' x:rel='#differences.between.http.and.mime' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY representation "<xref target='RFC7231' x:rel='#representations' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY GET "<xref target='RFC7231' x:rel='#GET' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY HEAD "<xref target='RFC7231' x:rel='#HEAD' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-allow "<xref target='RFC7231' x:rel='#header.allow' 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-content-encoding "<xref target='RFC7231' x:rel='#header.content-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-content-location "<xref target='RFC7231' x:rel='#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='RFC7231' x:rel='#header.content-type' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-date "<xref target='RFC7231' x:rel='#header.date' 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-expect "<xref target='RFC7231' x:rel='#header.expect' 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-last-modified "<xref target='RFC7232' x:rel='#header.last-modified' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-mime-version "<xref target='RFC7231' x:rel='#mime-version' 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-server "<xref target='RFC7231' x:rel='#header.server' 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 idempotent-methods "<xref target='RFC7231' x:rel='#idempotent.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY safe-methods "<xref target='RFC7231' x:rel='#safe.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY methods "<xref target='RFC7231' x:rel='#methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY OPTIONS "<xref target='RFC7231' x:rel='#OPTIONS' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY qvalue "<xref target='RFC7231' x:rel='#quality.values' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY request-header-fields "<xref target='RFC7231' x:rel='#request.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY response-control-data "<xref target='RFC7231' x:rel='#response.control.data' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY resource "<xref target='RFC7231' x:rel='#resources' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY semantics "<xref target='RFC7231' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY status-codes "<xref target='RFC7231' x:rel='#status.codes' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY status-1xx "<xref target='RFC7231' x:rel='#status.1xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY status-203 "<xref target='RFC7231' x:rel='#status.203' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY status-3xx "<xref target='RFC7231' x:rel='#status.3xx' 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-4xx "<xref target='RFC7231' x:rel='#status.4xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY status-413 "<xref target='RFC7231' x:rel='#status.413' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY status-414 "<xref target='RFC7231' x:rel='#status.414' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY iana-header-registry "<xref target='RFC7231' x:rel='#header.field.registry' 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="2145, 2616" updates="2817, 2818" category="std" x:maturity-level="proposed"
ipr="pre5378Trust200902" number="7230" consensus="yes"
xmlns:x='http://purl.org/net/xml2rfc/ext'>
<x:link rel="next" basename="rfc7231"/>
<!--<x:feedback template="mailto:[email protected]?subject={docname},%20%22{section}%22&body=<{ref}>:"/>-->
<front>
<title abbrev="HTTP/1.1 Message Syntax and Routing">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</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>
<email>[email protected]</email>
<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>
<email>[email protected]</email>
<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 message format</keyword>
<abstract>
<t>
The Hypertext Transfer Protocol (HTTP) is a stateless application-level
protocol for distributed, collaborative, hypertext information systems.
This document provides an overview of HTTP architecture and its associated
terminology, defines the "http" and "https" Uniform Resource Identifier
(URI) schemes, defines the HTTP/1.1 message syntax and parsing
requirements, and describes related security concerns for implementations.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="introduction">
<t>
The Hypertext Transfer Protocol (HTTP) is a stateless application-level
request/response protocol that uses extensible semantics and
self-descriptive message payloads for flexible interaction with
network-based hypertext information systems. This document is the first in
a series of documents that collectively form the HTTP/1.1 specification:
<list style="numbers">
<t>"Message Syntax and Routing" (this document)</t>
<t>"Semantics and Content" <xref target="RFC7231"/></t>
<t>"Conditional Requests" <xref target="RFC7232"/></t>
<t>"Range Requests" <xref target="RFC7233"/></t>
<t>"Caching" <xref target="RFC7234"/></t>
<t>"Authentication" <xref target="RFC7235"/></t>
</list>
</t>
<t>
This HTTP/1.1 specification obsoletes
<xref target="RFC2616" x:fmt="none">RFC 2616</xref> and
<xref target="RFC2145" x:fmt="none">RFC 2145</xref> (on HTTP versioning).
This specification also updates the use of CONNECT to establish a tunnel,
previously defined in <xref target="RFC2817" x:fmt="none">RFC 2817</xref>,
and defines the "https" URI scheme that was described informally in
<xref target="RFC2818" x:fmt="none">RFC 2818</xref>.
</t>
<t>
HTTP is a generic interface protocol for information systems. It is
designed to hide the details of how a service is implemented by presenting
a uniform interface to clients that is independent of the types of
resources provided. Likewise, servers do not need to be aware of each
client's purpose: an HTTP request can be considered in isolation rather
than being associated with a specific type of client or a predetermined
sequence of application steps. The result is a protocol that can be used
effectively in many different contexts and for which implementations can
evolve independently over time.
</t>
<t>
HTTP is also designed for use as an intermediation protocol for translating
communication to and from non-HTTP information systems.
HTTP proxies and gateways can provide access to alternative information
services by translating their diverse protocols into a hypertext
format that can be viewed and manipulated by clients in the same way
as HTTP services.
</t>
<t>
One consequence of this flexibility is that the protocol cannot be
defined in terms of what occurs behind the interface. Instead, we
are limited to defining the syntax of communication, the intent
of received communication, and the expected behavior of recipients.
If the communication is considered in isolation, then successful
actions ought to be reflected in corresponding changes to the
observable interface provided by servers. However, since multiple
clients might act in parallel and perhaps at cross-purposes, we
cannot require that such changes be observable beyond the scope
of a single response.
</t>
<t>
This document describes the architectural elements that are used or
referred to in HTTP, defines the "http" and "https" URI schemes,
describes overall network operation and connection management,
and defines HTTP message framing and forwarding requirements.
Our goal is to define all of the mechanisms necessary for HTTP message
handling that are independent of message semantics, thereby defining the
complete set of requirements for message parsers and
message-forwarding intermediaries.
</t>
<section title="Requirements Notation" anchor="intro.requirements">
<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 <xref target="conformance"/>.
</t>
</section>
<section title="Syntax Notation" anchor="notation">
<iref primary="true" item="Grammar" subitem="ALPHA"/>
<iref primary="true" item="Grammar" subitem="CR"/>
<iref primary="true" item="Grammar" subitem="CRLF"/>
<iref primary="true" item="Grammar" subitem="CTL"/>
<iref primary="true" item="Grammar" subitem="DIGIT"/>
<iref primary="true" item="Grammar" subitem="DQUOTE"/>
<iref primary="true" item="Grammar" subitem="HEXDIG"/>
<iref primary="true" item="Grammar" subitem="HTAB"/>
<iref primary="true" item="Grammar" subitem="LF"/>
<iref primary="true" item="Grammar" subitem="OCTET"/>
<iref primary="true" item="Grammar" subitem="SP"/>
<iref primary="true" item="Grammar" subitem="VCHAR"/>
<t>
This specification uses the Augmented Backus-Naur Form (ABNF) notation of
<xref target="RFC5234"/> with a list extension, defined in
<xref target="abnf.extension"/>, that allows for compact definition of
comma-separated lists using a '#' operator (similar to how the '*' operator
indicates repetition).
<xref target="collected.abnf"/> shows the collected grammar with all list
operators expanded to standard ABNF notation.
</t>
<t anchor="core.rules">
<x:anchor-alias value="ALPHA"/>
<x:anchor-alias value="CTL"/>
<x:anchor-alias value="CR"/>
<x:anchor-alias value="CRLF"/>
<x:anchor-alias value="DIGIT"/>
<x:anchor-alias value="DQUOTE"/>
<x:anchor-alias value="HEXDIG"/>
<x:anchor-alias value="HTAB"/>
<x:anchor-alias value="LF"/>
<x:anchor-alias value="OCTET"/>
<x:anchor-alias value="SP"/>
<x:anchor-alias value="VCHAR"/>
The following core rules are included by
reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>:
ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed),
OCTET (any 8-bit sequence of data), SP (space), and
VCHAR (any visible <xref target="USASCII"/> character).
</t>
<t>
As a convention, ABNF rule names prefixed with "obs-" denote
"obsolete" grammar rules that appear for historical reasons.
</t>
</section>
</section>
<section title="Architecture" anchor="architecture">
<t>
HTTP was created for the World Wide Web (WWW) architecture
and has evolved over time to support the scalability needs of a worldwide
hypertext system. Much of that architecture is reflected in the terminology
and syntax productions used to define HTTP.
</t>
<section title="Client/Server Messaging" anchor="operation">
<iref primary="true" item="client"/>
<iref primary="true" item="server"/>
<iref primary="true" item="connection"/>
<t>
HTTP is a stateless request/response protocol that operates by exchanging
<x:dfn>messages</x:dfn> (<xref target="http.message"/>) across a reliable
transport- or session-layer
"<x:dfn>connection</x:dfn>" (<xref target="connection.management"/>).
An HTTP "<x:dfn>client</x:dfn>" is a program that establishes a connection
to a server for the purpose of sending one or more HTTP requests.
An HTTP "<x:dfn>server</x:dfn>" is a program that accepts connections
in order to service HTTP requests by sending HTTP responses.
</t>
<iref primary="true" item="user agent"/>
<iref primary="true" item="origin server"/>
<iref primary="true" item="browser"/>
<iref primary="true" item="spider"/>
<iref primary="true" item="sender"/>
<iref primary="true" item="recipient"/>
<t>
The terms "client" and "server" refer only to the roles that
these programs perform for a particular connection. The same program
might act as a client on some connections and a server on others.
The term "<x:dfn>user agent</x:dfn>" refers to any of the various
client programs that initiate a request, including (but not limited to)
browsers, spiders (web-based robots), command-line tools, custom
applications, and mobile apps.
The term "<x:dfn>origin server</x:dfn>" refers to the program that can
originate authoritative responses for a given target resource.
The terms "<x:dfn>sender</x:dfn>" and "<x:dfn>recipient</x:dfn>" refer to
any implementation that sends or receives a given message, respectively.
</t>
<t>
HTTP relies upon the Uniform Resource Identifier (URI)
standard <xref target="RFC3986"/> to indicate the target resource
(<xref target="target-resource"/>) and relationships between resources.
Messages are passed in a format similar to that used by Internet mail
<xref target="RFC5322"/> and the Multipurpose Internet Mail Extensions
(MIME) <xref target="RFC2045"/> (see &diff-mime; for the differences
between HTTP and MIME messages).
</t>
<t>
Most HTTP communication consists of a retrieval request (GET) for
a representation of some resource identified by a URI. In the
simplest case, this might be accomplished via a single bidirectional
connection (===) between the user agent (UA) and the origin server (O).
</t>
<figure><artwork type="drawing">
request >
<x:highlight>UA</x:highlight> ======================================= <x:highlight>O</x:highlight>
< response
</artwork></figure>
<iref primary="true" item="message"/>
<iref primary="true" item="request"/>
<iref primary="true" item="response"/>
<t>
A client sends an HTTP request to a server in the form of a <x:dfn>request</x:dfn>
message, beginning with a request-line that includes a method, URI, and
protocol version (<xref target="request.line"/>),
followed by header fields containing
request modifiers, client information, and representation metadata
(<xref target="header.fields"/>),
an empty line to indicate the end of the header section, and finally
a message body containing the payload body (if any,
<xref target="message.body"/>).
</t>
<t>
A server responds to a client's request by sending one or more HTTP
<x:dfn>response</x:dfn>
messages, each beginning with a status line that
includes the protocol version, a success or error code, and textual
reason phrase (<xref target="status.line"/>),
possibly followed by header fields containing server
information, resource metadata, and representation metadata
(<xref target="header.fields"/>),
an empty line to indicate the end of the header section, and finally
a message body containing the payload body (if any,
<xref target="message.body"/>).
</t>
<t>
A connection might be used for multiple request/response exchanges,
as defined in <xref target="persistent.connections"/>.
</t>
<t>
The following example illustrates a typical message exchange for a
GET request (&GET;) on the URI "http://www.example.com/hello.txt":
</t>
<figure><preamble>
Client request:
</preamble><artwork type="message/http; msgtype="request"" x:indent-with=" ">
GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
</artwork></figure>
<figure><preamble>
Server response:
</preamble><artwork type="message/http; msgtype="response"" x:indent-with=" ">
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: <x:length-of target="exbody"/>
Vary: Accept-Encoding
Content-Type: text/plain
<x:span anchor="exbody">Hello World! My payload includes a trailing CRLF.
</x:span></artwork>
</figure>
</section>
<section title="Implementation Diversity" anchor="implementation-diversity">
<t>
When considering the design of HTTP, it is easy to fall into a trap of
thinking that all user agents are general-purpose browsers and all origin
servers are large public websites. That is not the case in practice.
Common HTTP user agents include household appliances, stereos, scales,
firmware update scripts, command-line programs, mobile apps,
and communication devices in a multitude of shapes and sizes. Likewise,
common HTTP origin servers include home automation units, configurable
networking components, office machines, autonomous robots, news feeds,
traffic cameras, ad selectors, and video-delivery platforms.
</t>
<t>
The term "user agent" does not imply that there is a human user directly
interacting with the software agent at the time of a request. In many
cases, a user agent is installed or configured to run in the background
and save its results for later inspection (or save only a subset of those
results that might be interesting or erroneous). Spiders, for example, are
typically given a start URI and configured to follow certain behavior while
crawling the Web as a hypertext graph.
</t>
<t>
The implementation diversity of HTTP means that not all user agents can
make interactive suggestions to their user or provide adequate warning for
security or privacy concerns. In the few cases where this
specification requires reporting of errors to the user, it is acceptable
for such reporting to only be observable in an error console or log file.
Likewise, requirements that an automated action be confirmed by the user
before proceeding might be met via advance configuration choices,
run-time options, or simple avoidance of the unsafe action; confirmation
does not imply any specific user interface or interruption of normal
processing if the user has already made that choice.
</t>
</section>
<section title="Intermediaries" anchor="intermediaries">
<iref primary="true" item="intermediary"/>
<t>
HTTP enables the use of intermediaries to satisfy requests through
a chain of connections. There are three common forms of HTTP
<x:dfn>intermediary</x:dfn>: proxy, gateway, and tunnel. In some cases,
a single intermediary might act as an origin server, proxy, gateway,
or tunnel, switching behavior based on the nature of each request.
</t>
<figure><artwork type="drawing">
> > > >
<x:highlight>UA</x:highlight> =========== <x:highlight>A</x:highlight> =========== <x:highlight>B</x:highlight> =========== <x:highlight>C</x:highlight> =========== <x:highlight>O</x:highlight>
< < < <
</artwork></figure>
<t>
The figure above shows three intermediaries (A, B, and C) between the
user agent and origin server. A request or response message that
travels the whole chain will pass through four separate connections.
Some HTTP communication options
might apply only to the connection with the nearest, non-tunnel
neighbor, only to the endpoints of the chain, or to all connections
along the chain. Although the diagram is linear, each participant might
be engaged in multiple, simultaneous communications. For example, B
might be receiving requests from many clients other than A, and/or
forwarding requests to servers other than C, at the same time that it
is handling A's request. Likewise, later requests might be sent through a
different path of connections, often based on dynamic configuration for
load balancing.
</t>
<t>
<iref primary="true" item="upstream"/><iref primary="true" item="downstream"/>
<iref primary="true" item="inbound"/><iref primary="true" item="outbound"/>
The terms "<x:dfn>upstream</x:dfn>" and "<x:dfn>downstream</x:dfn>" are
used to describe directional requirements in relation to the message flow:
all messages flow from upstream to downstream.
The terms "inbound" and "outbound" are used to describe directional
requirements in relation to the request route:
"<x:dfn>inbound</x:dfn>" means toward the origin server and
"<x:dfn>outbound</x:dfn>" means toward the user agent.
</t>
<t><iref primary="true" item="proxy"/>
A "<x:dfn>proxy</x:dfn>" is a message-forwarding agent that is selected by the
client, usually via local configuration rules, to receive requests
for some type(s) of absolute URI and attempt to satisfy those
requests via translation through the HTTP interface. Some translations
are minimal, such as for proxy requests for "http" URIs, whereas
other requests might require translation to and from entirely different
application-level protocols. Proxies are often used to group an
organization's HTTP requests through a common intermediary for the
sake of security, annotation services, or shared caching. Some proxies
are designed to apply transformations to selected messages or payloads
while they are being forwarded, as described in
<xref target="message.transformations"/>.
</t>
<t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/>
<iref primary="true" item="accelerator"/>
A "<x:dfn>gateway</x:dfn>" (a.k.a. "<x:dfn>reverse proxy</x:dfn>") is an
intermediary that acts as an origin server for the outbound connection but
translates received requests and forwards them inbound to another server or
servers. Gateways are often used to encapsulate legacy or untrusted
information services, to improve server performance through
"<x:dfn>accelerator</x:dfn>" caching, and to enable partitioning or load
balancing of HTTP services across multiple machines.
</t>
<t>
All HTTP requirements applicable to an origin server
also apply to the outbound communication of a gateway.
A gateway communicates with inbound servers using any protocol that
it desires, including private extensions to HTTP that are outside
the scope of this specification. However, an HTTP-to-HTTP gateway
that wishes to interoperate with third-party HTTP servers ought to conform
to user agent requirements on the gateway's inbound connection.
</t>
<t><iref primary="true" item="tunnel"/>
A "<x:dfn>tunnel</x:dfn>" acts as a blind relay between two connections
without changing the messages. Once active, a tunnel is not
considered a party to the HTTP communication, though the tunnel might
have been initiated by an HTTP request. A tunnel ceases to exist when
both ends of the relayed connection are closed. Tunnels are used to
extend a virtual connection through an intermediary, such as when
Transport Layer Security (TLS, <xref target="RFC5246"/>) is used to
establish confidential communication through a shared firewall proxy.
</t>
<t>
The above categories for intermediary only consider those acting as
participants in the HTTP communication. There are also intermediaries
that can act on lower layers of the network protocol stack, filtering or
redirecting HTTP traffic without the knowledge or permission of message
senders. Network intermediaries are indistinguishable (at a protocol level)
from a man-in-the-middle attack, often introducing security flaws or
interoperability problems due to mistakenly violating HTTP semantics.
</t>
<t><iref primary="true" item="interception proxy"/>
<iref primary="true" item="transparent proxy"/>
<iref primary="true" item="captive portal"/>
For example, an
"<x:dfn>interception proxy</x:dfn>" <xref target="RFC3040"/> (also commonly
known as a "<x:dfn>transparent proxy</x:dfn>" <xref target="RFC1919"/> or
"<x:dfn>captive portal</x:dfn>")
differs from an HTTP proxy because it is not selected by the client.
Instead, an interception proxy filters or redirects outgoing TCP port 80
packets (and occasionally other common port traffic).
Interception proxies are commonly found on public network access points,
as a means of enforcing account subscription prior to allowing use of
non-local Internet services, and within corporate firewalls to enforce
network usage policies.
</t>
<t>
HTTP is defined as a stateless protocol, meaning that each request message
can be understood in isolation. Many implementations depend on HTTP's
stateless design in order to reuse proxied connections or dynamically
load balance requests across multiple servers. Hence, a server &MUST-NOT;
assume that two requests on the same connection are from the same user
agent unless the connection is secured and specific to that agent.
Some non-standard HTTP extensions (e.g., <xref target="RFC4559"/>) have
been known to violate this requirement, resulting in security and
interoperability problems.
</t>
</section>
<section title="Caches" anchor="caches">
<iref primary="true" item="cache"/>
<t>
A "<x:dfn>cache</x:dfn>" is a local store of previous response messages and the
subsystem that controls its message storage, retrieval, and deletion.
A cache stores cacheable responses in order to reduce the response
time and network bandwidth consumption on future, equivalent
requests. Any client or server &MAY; employ a cache, though a cache
cannot be used by a server while it is acting as a tunnel.
</t>
<t>
The effect of a cache is that the request/response chain is shortened
if one of the participants along the chain has a cached response
applicable to that request. The following illustrates the resulting
chain if B has a cached copy of an earlier response from O (via C)
for a request that has not been cached by UA or A.
</t>
<figure><artwork type="drawing">
> >
<x:highlight>UA</x:highlight> =========== <x:highlight>A</x:highlight> =========== <x:highlight>B</x:highlight> - - - - - - <x:highlight>C</x:highlight> - - - - - - <x:highlight>O</x:highlight>
< <
</artwork></figure>
<t><iref primary="true" item="cacheable"/>
A response is "<x:dfn>cacheable</x:dfn>" if a cache is allowed to store a copy of
the response message for use in answering subsequent requests.
Even when a response is cacheable, there might be additional
constraints placed by the client or by the origin server on when
that cached response can be used for a particular request. HTTP
requirements for cache behavior and cacheable responses are
defined in &caching-overview;.
</t>
<t>
There is a wide variety of architectures and configurations
of caches deployed across the World Wide Web and
inside large organizations. These include national hierarchies
of proxy caches to save transoceanic bandwidth, collaborative systems that
broadcast or multicast cache entries, archives of pre-fetched cache
entries for use in off-line or high-latency environments, and so on.
</t>
</section>
<section title="Conformance and Error Handling" anchor="conformance">
<t>
This specification targets conformance criteria according to the role of
a participant in HTTP communication. Hence, HTTP requirements are placed
on senders, recipients, clients, servers, user agents, intermediaries,
origin servers, proxies, gateways, or caches, depending on what behavior
is being constrained by the requirement. Additional (social) requirements
are placed on implementations, resource owners, and protocol element
registrations when they apply beyond the scope of a single communication.
</t>
<t>
The verb "generate" is used instead of "send" where a requirement
differentiates between creating a protocol element and merely forwarding a
received element downstream.
</t>
<t>
An implementation is considered conformant if it complies with all of the
requirements associated with the roles it partakes in HTTP.
</t>
<t>
Conformance includes both the syntax and semantics of protocol
elements. A sender &MUST-NOT; generate protocol elements that convey a
meaning that is known by that sender to be false. A sender &MUST-NOT;
generate protocol elements that do not match the grammar defined by the
corresponding ABNF rules. Within a given message, a sender &MUST-NOT;
generate protocol elements or syntax alternatives that are only allowed to
be generated by participants in other roles (i.e., a role that the sender
does not have for that message).
</t>
<t>
When a received protocol element is parsed, the recipient &MUST; be able to
parse any value of reasonable length that is applicable to the recipient's
role and that matches the grammar defined by the corresponding ABNF rules.
Note, however, that some received protocol elements might not be parsed.
For example, an intermediary forwarding a message might parse a
header-field into generic field-name and field-value components, but then
forward the header field without further parsing inside the field-value.
</t>
<t>
HTTP does not have specific length limitations for many of its protocol
elements because the lengths that might be appropriate will vary widely,
depending on the deployment context and purpose of the implementation.
Hence, interoperability between senders and recipients depends on shared
expectations regarding what is a reasonable length for each protocol
element. Furthermore, what is commonly understood to be a reasonable length
for some protocol elements has changed over the course of the past two
decades of HTTP use and is expected to continue changing in the future.
</t>
<t>
At a minimum, a recipient &MUST; be able to parse and process protocol
element lengths that are at least as long as the values that it generates
for those same protocol elements in other messages. For example, an origin
server that publishes very long URI references to its own resources needs
to be able to parse and process those same references when received as a
request target.
</t>
<t>
A recipient &MUST; interpret a received protocol element according to the
semantics defined for it by this specification, including extensions to
this specification, unless the recipient has determined (through experience
or configuration) that the sender incorrectly implements what is implied by
those semantics.
For example, an origin server might disregard the contents of a received
<x:ref>Accept-Encoding</x:ref> header field if inspection of the
<x:ref>User-Agent</x:ref> header field indicates a specific implementation
version that is known to fail on receipt of certain content codings.
</t>
<t>
Unless noted otherwise, a recipient &MAY; attempt to recover a usable
protocol element from an invalid construct. HTTP does not define
specific error handling mechanisms except when they have a direct impact
on security, since different applications of the protocol require
different error handling strategies. For example, a Web browser might
wish to transparently recover from a response where the
<x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
whereas a systems control client might consider any form of error recovery
to be dangerous.
</t>
</section>
<section title="Protocol Versioning" anchor="http.version">
<x:anchor-alias value="HTTP-version"/>
<x:anchor-alias value="HTTP-name"/>
<t>
HTTP uses a "<major>.<minor>" numbering scheme to indicate
versions of the protocol. This specification defines version "1.1".
The protocol version as a whole indicates the sender's conformance
with the set of requirements laid out in that version's corresponding
specification of HTTP.
</t>
<t>
The version of an HTTP message is indicated by an HTTP-version field
in the first line of the message. HTTP-version is case-sensitive.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-version"/><iref primary="true" item="Grammar" subitem="HTTP-name"/>
<x:ref>HTTP-version</x:ref> = <x:ref>HTTP-name</x:ref> "/" <x:ref>DIGIT</x:ref> "." <x:ref>DIGIT</x:ref>
<x:ref>HTTP-name</x:ref> = <x:abnf-char-sequence>"HTTP"</x:abnf-char-sequence> ; "HTTP", case-sensitive
</artwork></figure>
<t>
The HTTP version number consists of two decimal digits separated by a "."
(period or decimal point). The first digit ("major version") indicates the
HTTP messaging syntax, whereas the second digit ("minor version") indicates
the highest minor version within that major version to which the sender is
conformant and able to understand for future communication. The minor
version advertises the sender's communication capabilities even when the
sender is only using a backwards-compatible subset of the protocol,
thereby letting the recipient know that more advanced features can
be used in response (by servers) or in future requests (by clients).
</t>
<t>
When an HTTP/1.1 message is sent to an HTTP/1.0 recipient
<xref target="RFC1945"/> or a recipient whose version is unknown,
the HTTP/1.1 message is constructed such that it can be interpreted
as a valid HTTP/1.0 message if all of the newer features are ignored.
This specification places recipient-version requirements on some
new features so that a conformant sender will only use compatible
features until it has determined, through configuration or the
receipt of a message, that the recipient supports HTTP/1.1.
</t>
<t>
The interpretation of a header field does not change between minor
versions of the same major HTTP version, though the default
behavior of a recipient in the absence of such a field can change.
Unless specified otherwise, header fields defined in HTTP/1.1 are
defined for all versions of HTTP/1.x. In particular, the <x:ref>Host</x:ref>
and <x:ref>Connection</x:ref> header fields ought to be implemented by all
HTTP/1.x implementations whether or not they advertise conformance with
HTTP/1.1.
</t>
<t>
New header fields can be introduced without changing the protocol version
if their defined semantics allow them to be safely ignored by recipients
that do not recognize them. Header field extensibility is discussed in
<xref target="field.extensibility"/>.
</t>
<t>
Intermediaries that process HTTP messages (i.e., all intermediaries
other than those acting as tunnels) &MUST; send their own HTTP-version
in forwarded messages. In other words, they are not allowed to blindly
forward the first line of an HTTP message without ensuring that the
protocol version in that message matches a version to which that
intermediary is conformant for both the receiving and
sending of messages. Forwarding an HTTP message without rewriting
the HTTP-version might result in communication errors when downstream
recipients use the message sender's version to determine what features
are safe to use for later communication with that sender.
</t>
<t>
A client &SHOULD; send a request version equal to the highest
version to which the client is conformant and
whose major version is no higher than the highest version supported
by the server, if this is known. A client &MUST-NOT; send a
version to which it is not conformant.
</t>
<t>
A client &MAY; send a lower request version if it is known that
the server incorrectly implements the HTTP specification, but only
after the client has attempted at least one normal request and determined
from the response status code or header fields (e.g., <x:ref>Server</x:ref>) that
the server improperly handles higher request versions.
</t>
<t>
A server &SHOULD; send a response version equal to the highest version to
which the server is conformant that has a major version less than or equal
to the one received in the request.
A server &MUST-NOT; send a version to which it is not conformant.
A server can send a <x:ref>505 (HTTP Version Not Supported)</x:ref>
response if it wishes, for any reason, to refuse service of the client's
major protocol version.
</t>
<t>
A server &MAY; send an HTTP/1.0 response to a request
if it is known or suspected that the client incorrectly implements the
HTTP specification and is incapable of correctly processing later
version responses, such as when a client fails to parse the version
number correctly or when an intermediary is known to blindly forward
the HTTP-version even when it doesn't conform to the given minor
version of the protocol. Such protocol downgrades &SHOULD-NOT; be
performed unless triggered by specific client attributes, such as when
one or more of the request header fields (e.g., <x:ref>User-Agent</x:ref>)
uniquely match the values sent by a client known to be in error.
</t>
<t>
The intention of HTTP's versioning design is that the major number
will only be incremented if an incompatible message syntax is
introduced, and that the minor number will only be incremented when
changes made to the protocol have the effect of adding to the message
semantics or implying additional capabilities of the sender. However,
the minor version was not incremented for the changes introduced between
<xref target="RFC2068"/> and <xref target="RFC2616"/>, and this revision
has specifically avoided any such changes to the protocol.
</t>
<t>
When an HTTP message is received with a major version number that the
recipient implements, but a higher minor version number than what the
recipient implements, the recipient &SHOULD; process the message as if it
were in the highest minor version within that major version to which the
recipient is conformant. A recipient can assume that a message with a
higher minor version, when sent to a recipient that has not yet indicated
support for that higher version, is sufficiently backwards-compatible to be
safely processed by any implementation of the same major version.
</t>
</section>
<section title="Uniform Resource Identifiers" anchor="uri">
<iref primary="true" item="resource"/>
<t>
Uniform Resource Identifiers (URIs) <xref target="RFC3986"/> are used
throughout HTTP as the means for identifying resources (&resource;).
URI references are used to target requests, indicate redirects, and define
relationships.
</t>
<x:anchor-alias value="URI-reference"/>
<x:anchor-alias value="absolute-URI"/>
<x:anchor-alias value="relative-part"/>
<x:anchor-alias value="scheme"/>
<x:anchor-alias value="authority"/>
<x:anchor-alias value="uri-host"/>
<x:anchor-alias value="port"/>
<x:anchor-alias value="path"/>
<x:anchor-alias value="path-abempty"/>
<x:anchor-alias value="segment"/>
<x:anchor-alias value="query"/>
<x:anchor-alias value="fragment"/>
<x:anchor-alias value="absolute-path"/>
<x:anchor-alias value="partial-URI"/>
<t>
The definitions of "URI-reference",
"absolute-URI", "relative-part", "scheme", "authority", "port", "host",
"path-abempty", "segment", "query", and "fragment" are adopted from the
URI generic syntax.
An "absolute-path" rule is defined for protocol elements that can contain a
non-empty path component. (This rule differs slightly from the path-abempty
rule of RFC 3986, which allows for an empty path to be used in references,
and path-absolute rule, which does not allow paths that begin with "//".)
A "partial-URI" rule is defined for protocol elements
that can contain a relative URI but not a fragment component.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="URI-reference"><!--exported production--></iref><iref primary="true" item="Grammar" subitem="absolute-URI"/><iref primary="true" item="Grammar" subitem="scheme"/><iref primary="true" item="Grammar" subitem="authority"/><iref primary="true" item="Grammar" subitem="absolute-path"/><iref primary="true" item="Grammar" subitem="port"/><iref primary="true" item="Grammar" subitem="query"/><iref primary="true" item="Grammar" subitem="fragment"/><iref primary="true" item="Grammar" subitem="segment"/><iref primary="true" item="Grammar" subitem="uri-host"/><iref primary="true" item="Grammar" subitem="partial-URI"><!--exported production--></iref>
<x:ref>URI-reference</x:ref> = <URI-reference, see <xref target="RFC3986" x:fmt="," x:sec="4.1"/>>
<x:ref>absolute-URI</x:ref> = <absolute-URI, see <xref target="RFC3986" x:fmt="," x:sec="4.3"/>>
<x:ref>relative-part</x:ref> = <relative-part, see <xref target="RFC3986" x:fmt="," x:sec="4.2"/>>
<x:ref>scheme</x:ref> = <scheme, see <xref target="RFC3986" x:fmt="," x:sec="3.1"/>>
<x:ref>authority</x:ref> = <authority, see <xref target="RFC3986" x:fmt="," x:sec="3.2"/>>
<x:ref>uri-host</x:ref> = <host, see <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>>
<x:ref>port</x:ref> = <port, see <xref target="RFC3986" x:fmt="," x:sec="3.2.3"/>>
<x:ref>path-abempty</x:ref> = <path-abempty, see <xref target="RFC3986" x:fmt="," x:sec="3.3"/>>
<x:ref>segment</x:ref> = <segment, see <xref target="RFC3986" x:fmt="," x:sec="3.3"/>>
<x:ref>query</x:ref> = <query, see <xref target="RFC3986" x:fmt="," x:sec="3.4"/>>
<x:ref>fragment</x:ref> = <fragment, see <xref target="RFC3986" x:fmt="," x:sec="3.5"/>>
<x:ref>absolute-path</x:ref> = 1*( "/" segment )
<x:ref>partial-URI</x:ref> = relative-part [ "?" query ]
</artwork></figure>
<t>
Each protocol element in HTTP that allows a URI reference will indicate
in its ABNF production whether the element allows any form of reference
(URI-reference), only a URI in absolute form (absolute-URI), only the
path and optional query components, or some combination of the above.
Unless otherwise indicated, URI references are parsed
relative to the effective request URI
(<xref target="effective.request.uri"/>).
</t>
<section title="http URI Scheme" anchor="http.uri">
<x:anchor-alias value="http-URI"/>
<iref item="http URI scheme" primary="true"/>
<iref item="URI scheme" subitem="http" primary="true"/>
<t>
The "http" URI scheme is hereby defined for the purpose of minting
identifiers according to their association with the hierarchical
namespace governed by a potential HTTP origin server listening for
TCP (<xref target="RFC0793"/>) connections on a given port.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URI"><!--terminal production--></iref>
<x:ref>http-URI</x:ref> = "http:" "//" <x:ref>authority</x:ref> <x:ref>path-abempty</x:ref> [ "?" <x:ref>query</x:ref> ]
[ "#" <x:ref>fragment</x:ref> ]
</artwork></figure>
<t>
The origin server for an "http" URI is identified by the
<x:ref>authority</x:ref> component, which includes a host identifier
and optional TCP port (<xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>).
The hierarchical path component and optional query component serve as an
identifier for a potential target resource within that origin server's name
space. The optional fragment component allows for indirect identification
of a secondary resource, independent of the URI scheme, as defined in
<xref target="RFC3986" x:fmt="of" x:sec="3.5"/>.
</t>
<t>
A sender &MUST-NOT; generate an "http" URI with an empty host identifier.
A recipient that processes such a URI reference &MUST; reject it as invalid.
</t>
<t>
If the host identifier is provided as an IP address, the origin server is
the listener (if any) on the indicated TCP port at that IP address.
If host is a registered name, the registered name is an indirect identifier
for use with a name resolution service, such as DNS, to find an address for
that origin server.
If the port subcomponent is empty or not given, TCP port 80 (the
reserved port for WWW services) is the default.
</t>
<t>
Note that the presence of a URI with a given authority component does not
imply that there is always an HTTP server listening for connections on
that host and port. Anyone can mint a URI. What the authority component
determines is who has the right to respond authoritatively to requests that
target the identified resource. The delegated nature of registered names
and IP addresses creates a federated namespace, based on control over the
indicated host and port, whether or not an HTTP server is present.
See <xref target="establishing.authority"/> for security considerations
related to establishing authority.
</t>
<t>
When an "http" URI is used within a context that calls for access to the
indicated resource, a client &MAY; attempt access by resolving
the host to an IP address, establishing a TCP connection to that address
on the indicated port, and sending an HTTP request message
(<xref target="http.message"/>) containing the URI's identifying data
(<xref target="message.routing"/>) to the server.
If the server responds to that request with a non-interim HTTP response
message, as described in &status-codes;, then that response
is considered an authoritative answer to the client's request.
</t>
<t>
Although HTTP is independent of the transport protocol, the "http"
scheme is specific to TCP-based services because the name delegation
process depends on TCP for establishing authority.
An HTTP service based on some other underlying connection protocol
would presumably be identified using a different URI scheme, just as
the "https" scheme (below) is used for resources that require an
end-to-end secured connection. Other protocols might also be used to
provide access to "http" identified resources — it is only the
authoritative interface that is specific to TCP.
</t>
<t>
The URI generic syntax for authority also includes a deprecated
userinfo subcomponent (<xref target="RFC3986" x:fmt="," x:sec="3.2.1"/>)
for including user authentication information in the URI. Some
implementations make use of the userinfo component for internal
configuration of authentication information, such as within command
invocation options, configuration files, or bookmark lists, even
though such usage might expose a user identifier or password.
A sender &MUST-NOT; generate the userinfo subcomponent (and its "@"
delimiter) when an "http" URI reference is generated within a message as a
request target or header field value.
Before making use of an "http" URI reference received from an untrusted
source, a recipient &SHOULD; parse for userinfo and treat its presence as
an error; it is likely being used to obscure the authority for the sake of
phishing attacks.
</t>
</section>
<section title="https URI Scheme" anchor="https.uri">
<x:anchor-alias value="https-URI"/>
<iref item="https URI scheme"/>
<iref item="URI scheme" subitem="https"/>
<t>
The "https" URI scheme is hereby defined for the purpose of minting
identifiers according to their association with the hierarchical
namespace governed by a potential HTTP origin server listening to a
given TCP port for TLS-secured connections (<xref target="RFC5246"/>).
</t>
<t>
All of the requirements listed above for the "http" scheme are also
requirements for the "https" scheme, except that TCP port 443 is the
default if the port subcomponent is empty or not given,
and the user agent &MUST; ensure that its connection to the origin
server is secured through the use of strong encryption, end-to-end,
prior to sending the first HTTP request.
</t>
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="https-URI"><!--terminal production--></iref>
<x:ref>https-URI</x:ref> = "https:" "//" <x:ref>authority</x:ref> <x:ref>path-abempty</x:ref> [ "?" <x:ref>query</x:ref> ]
[ "#" <x:ref>fragment</x:ref> ]
</artwork></figure>
<t>
Note that the "https" URI scheme depends on both TLS and TCP for
establishing authority.
Resources made available via the "https" scheme have no shared
identity with the "http" scheme even if their resource identifiers
indicate the same authority (the same host listening to the same
TCP port). They are distinct namespaces and are considered to be
distinct origin servers. However, an extension to HTTP that is
defined to apply to entire host domains, such as the Cookie protocol
<xref target="RFC6265"/>, can allow information
set by one service to impact communication with other services
within a matching group of host domains.
</t>
<t>
The process for authoritative access to an "https" identified
resource is defined in <xref target="RFC2818"/>.
</t>
</section>
<section title="http and https URI Normalization and Comparison" anchor="uri.comparison">
<t>
Since the "http" and "https" schemes conform to the URI generic syntax,
such URIs are normalized and compared according to the algorithm defined
in <xref target="RFC3986" x:fmt="of" x:sec="6"/>, using the defaults
described above for each scheme.
</t>
<t>
If the port is equal to the default port for a scheme, the normal form is
to omit the port subcomponent. When not being used in absolute form as the
request target of an OPTIONS request, an empty path component is equivalent
to an absolute path of "/", so the normal form is to provide a path of "/"
instead. The scheme and host are case-insensitive and normally provided in
lowercase; all other components are compared in a case-sensitive manner.
Characters other than those in the "reserved" set are equivalent to their
percent-encoded octets: the normal form is to not encode them
(see Sections <xref target="RFC3986" x:fmt="number" x:sec="2.1"/> and
<xref target="RFC3986" x:fmt="number" x:sec="2.2"/> of
<xref target="RFC3986"/>).
</t>
<t>
For example, the following three URIs are equivalent:
</t>