rfc2616-sec6.html
9.87 KB
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
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns='http://www.w3.org/1999/xhtml'>
<head><title>HTTP/1.1: Response</title></head>
<body><address>part of <a rev='Section' href='rfc2616.html'>Hypertext Transfer Protocol -- HTTP/1.1</a><br />
RFC 2616 Fielding, et al.</address>
<h2><a id='sec6'>6</a> Response</h2>
<p>
After receiving and interpreting a request message, a server responds
with an HTTP response message.
</p>
<pre> Response = Status-Line ; Section 6.1
*(( general-header ; Section <a rel='xref' href='rfc2616-sec4.html#sec4.5'>4.5</a>
| response-header ; Section <a rel='xref' href='rfc2616-sec6.html#sec6.2'>6.2</a>
| entity-header ) CRLF) ; Section <a rel='xref' href='rfc2616-sec7.html#sec7.1'>7.1</a>
CRLF
[ message-body ] ; Section <a rel='xref' href='rfc2616-sec7.html#sec7.2'>7.2</a>
</pre>
<h3><a id='sec6.1'>6.1</a> Status-Line</h3>
<p>
The first line of a Response message is the Status-Line, consisting
of the protocol version followed by a numeric status code and its
associated textual phrase, with each element separated by SP
characters. No CR or LF is allowed except in the final CRLF sequence.
</p>
<pre> Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
</pre>
<h3><a id='sec6.1.1'>6.1.1</a> Status Code and Reason Phrase</h3>
<p>
The Status-Code element is a 3-digit integer result code of the
attempt to understand and satisfy the request. These codes are fully
defined in section 10. The Reason-Phrase is intended to give a short
textual description of the Status-Code. The Status-Code is intended
for use by automata and the Reason-Phrase is intended for the human
user. The client is not required to examine or display the Reason-
Phrase.
</p>
<p>
The first digit of the Status-Code defines the class of response. The
last two digits do not have any categorization role. There are 5
values for the first digit:
</p>
<pre> - 1xx: Informational - Request received, continuing process
</pre>
<pre> - 2xx: Success - The action was successfully received,
understood, and accepted
</pre>
<pre> - 3xx: Redirection - Further action must be taken in order to
complete the request
</pre>
<pre> - 4xx: Client Error - The request contains bad syntax or cannot
be fulfilled
</pre>
<pre> - 5xx: Server Error - The server failed to fulfill an apparently
valid request
</pre>
<p>
The individual values of the numeric status codes defined for
HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
presented below. The reason phrases listed here are only
recommendations -- they MAY be replaced by local equivalents without
affecting the protocol.
</p>
<pre> Status-Code =
"100" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.1.1'>10.1.1</a>: Continue
| "101" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.1.2'>10.1.2</a>: Switching Protocols
| "200" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.2.1'>10.2.1</a>: OK
| "201" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.2.2'>10.2.2</a>: Created
| "202" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.2.3'>10.2.3</a>: Accepted
| "203" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.2.4'>10.2.4</a>: Non-Authoritative Information
| "204" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.2.5'>10.2.5</a>: No Content
| "205" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.2.6'>10.2.6</a>: Reset Content
| "206" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.2.7'>10.2.7</a>: Partial Content
| "300" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.3.1'>10.3.1</a>: Multiple Choices
| "301" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.3.2'>10.3.2</a>: Moved Permanently
| "302" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.3.3'>10.3.3</a>: Found
| "303" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.3.4'>10.3.4</a>: See Other
| "304" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.3.5'>10.3.5</a>: Not Modified
| "305" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.3.6'>10.3.6</a>: Use Proxy
| "307" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.3.8'>10.3.8</a>: Temporary Redirect
| "400" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.4.1'>10.4.1</a>: Bad Request
| "401" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.4.2'>10.4.2</a>: Unauthorized
| "402" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.4.3'>10.4.3</a>: Payment Required
| "403" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.4.4'>10.4.4</a>: Forbidden
| "404" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.4.5'>10.4.5</a>: Not Found
| "405" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.4.6'>10.4.6</a>: Method Not Allowed
| "406" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.4.7'>10.4.7</a>: Not Acceptable
</pre>
<pre> | "407" ; Section 10.4.8: Proxy Authentication Required
| "408" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.4.9'>10.4.9</a>: Request Time-out
| "409" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.4.10'>10.4.10</a>: Conflict
| "410" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.4.11'>10.4.11</a>: Gone
| "411" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.4.12'>10.4.12</a>: Length Required
| "412" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.4.13'>10.4.13</a>: Precondition Failed
| "413" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.4.14'>10.4.14</a>: Request Entity Too Large
| "414" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.4.15'>10.4.15</a>: Request-URI Too Large
| "415" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.4.16'>10.4.16</a>: Unsupported Media Type
| "416" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.4.17'>10.4.17</a>: Requested range not satisfiable
| "417" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.4.18'>10.4.18</a>: Expectation Failed
| "500" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.5.1'>10.5.1</a>: Internal Server Error
| "501" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.5.2'>10.5.2</a>: Not Implemented
| "502" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.5.3'>10.5.3</a>: Bad Gateway
| "503" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.5.4'>10.5.4</a>: Service Unavailable
| "504" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.5.5'>10.5.5</a>: Gateway Time-out
| "505" ; Section <a rel='xref' href='rfc2616-sec10.html#sec10.5.6'>10.5.6</a>: HTTP Version not supported
| extension-code
</pre>
<pre> extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
</pre>
<p>
HTTP status codes are extensible. HTTP applications are not required
to understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST
understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the
x00 status code of that class, with the exception that an
unrecognized response MUST NOT be cached. For example, if an
unrecognized status code of 431 is received by the client, it can
safely assume that there was something wrong with its request and
treat the response as if it had received a 400 status code. In such
cases, user agents SHOULD present to the user the entity returned
with the response, since that entity is likely to include human-
readable information which will explain the unusual status.
</p>
<h3><a id='sec6.2'>6.2</a> Response Header Fields</h3>
<p>
The response-header fields allow the server to pass additional
information about the response which cannot be placed in the Status-
Line. These header fields give information about the server and about
further access to the resource identified by the Request-URI.
</p>
<pre> response-header = Accept-Ranges ; Section 14.5
| Age ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.6'>14.6</a>
| ETag ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.19'>14.19</a>
| Location ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.30'>14.30</a>
| Proxy-Authenticate ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.33'>14.33</a>
</pre>
<pre> | Retry-After ; Section 14.37
| Server ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.38'>14.38</a>
| Vary ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.44'>14.44</a>
| WWW-Authenticate ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.47'>14.47</a>
</pre>
<p>
Response-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics of response-
header fields if all parties in the communication recognize them to
be response-header fields. Unrecognized header fields are treated as
entity-header fields.
</p>
</body></html>