1 | // Licensed to the Apache Software Foundation (ASF) under one |
2 | // or more contributor license agreements. See the NOTICE file |
3 | // distributed with this work for additional information |
4 | // regarding copyright ownership. The ASF licenses this file |
5 | // to you under the Apache License, Version 2.0 (the |
6 | // "License"); you may not use this file except in compliance |
7 | // with the License. You may obtain a copy of the License at |
8 | // |
9 | // http://www.apache.org/licenses/LICENSE-2.0 |
10 | // |
11 | // Unless required by applicable law or agreed to in writing, |
12 | // software distributed under the License is distributed on an |
13 | // "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY |
14 | // KIND, either express or implied. See the License for the |
15 | // specific language governing permissions and limitations |
16 | // under the License. |
17 | |
18 | |
19 | #ifndef BRPC_HTTP_STATUS_CODE_H |
20 | #define BRPC_HTTP_STATUS_CODE_H |
21 | |
22 | |
23 | namespace brpc { |
24 | |
25 | // Read the description of a status code carefully before using it |
26 | |
27 | // http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html |
28 | // Status-Code = |
29 | // "100" ; Section 10.1.1: Continue |
30 | // | "101" ; Section 10.1.2: Switching Protocols |
31 | // | "200" ; Section 10.2.1: OK |
32 | // | "201" ; Section 10.2.2: Created |
33 | // | "202" ; Section 10.2.3: Accepted |
34 | // | "203" ; Section 10.2.4: Non-Authoritative Information |
35 | // | "204" ; Section 10.2.5: No Content |
36 | // | "205" ; Section 10.2.6: Reset Content |
37 | // | "206" ; Section 10.2.7: Partial Content |
38 | // | "300" ; Section 10.3.1: Multiple Choices |
39 | // | "301" ; Section 10.3.2: Moved Permanently |
40 | // | "302" ; Section 10.3.3: Found |
41 | // | "303" ; Section 10.3.4: See Other |
42 | // | "304" ; Section 10.3.5: Not Modified |
43 | // | "305" ; Section 10.3.6: Use Proxy |
44 | // | "307" ; Section 10.3.8: Temporary Redirect |
45 | // | "400" ; Section 10.4.1: Bad Request |
46 | // | "401" ; Section 10.4.2: Unauthorized |
47 | // | "402" ; Section 10.4.3: Payment Required |
48 | // | "403" ; Section 10.4.4: Forbidden |
49 | // | "404" ; Section 10.4.5: Not Found |
50 | // | "405" ; Section 10.4.6: Method Not Allowed |
51 | // | "406" ; Section 10.4.7: Not Acceptable |
52 | // | "407" ; Section 10.4.8: Proxy Authentication Required |
53 | // | "408" ; Section 10.4.9: Request Time-out |
54 | // | "409" ; Section 10.4.10: Conflict |
55 | // | "410" ; Section 10.4.11: Gone |
56 | // | "411" ; Section 10.4.12: Length Required |
57 | // | "412" ; Section 10.4.13: Precondition Failed |
58 | // | "413" ; Section 10.4.14: Request Entity Too Large |
59 | // | "414" ; Section 10.4.15: Request-URI Too Large |
60 | // | "415" ; Section 10.4.16: Unsupported Media Type |
61 | // | "416" ; Section 10.4.17: Requested range not satisfiable |
62 | // | "417" ; Section 10.4.18: Expectation Failed |
63 | // | "500" ; Section 10.5.1: Internal Server Error |
64 | // | "501" ; Section 10.5.2: Not Implemented |
65 | // | "502" ; Section 10.5.3: Bad Gateway |
66 | // | "503" ; Section 10.5.4: Service Unavailable |
67 | // | "504" ; Section 10.5.5: Gateway Time-out |
68 | // | "505" ; Section 10.5.6: HTTP Version not supported |
69 | // | extension-code |
70 | |
71 | // Return the reason phrase of a given status_code. |
72 | // "Unknown status code (|status_code|)" will be returned if the status_code is |
73 | // unknown |
74 | // This function is thread-safe and NULL is never supposed to be returned |
75 | // |
76 | // NOTICE: the memory referenced by the pointer returned before might be reused |
77 | // when this function is called again, so please DON'T try to cache the return |
78 | // value into a container. Directly copy the memory instead. |
79 | const char *HttpReasonPhrase(int status_code); |
80 | |
81 | // Convert brpc error code to related status code. |
82 | int ErrorCodeToStatusCode(int error_code); |
83 | |
84 | // Informational 1xx |
85 | // This class of status code indicates a provisional response, consisting |
86 | // only of the Status-Line and optional headers, and is terminated by an |
87 | // empty line. There are no required headers for this class of status code. |
88 | // Since HTTP/1.0 did not define any 1xx status codes, servers MUST NOT |
89 | // send a 1xx response to an HTTP/1.0 client except under experimental |
90 | // conditions. |
91 | // |
92 | // A client MUST be prepared to accept one or more 1xx status responses |
93 | // prior to a regular response, even if the client does not expect a 100 |
94 | // (Continue) status message. Unexpected 1xx status responses MAY be |
95 | // ignored by a user agent. |
96 | // |
97 | // Proxies MUST forward 1xx responses, unless the connection between the |
98 | // proxy and its client has been closed, or unless the proxy itself |
99 | // requested the generation of the 1xx response. (For example, if a |
100 | // |
101 | // proxy adds a "Expect: 100-continue" field when it forwards a request; |
102 | // then it need not forward the corresponding 100 (Continue) response(s).) |
103 | |
104 | // 100 Continue |
105 | // |
106 | // The client SHOULD continue with its request. This interim response is |
107 | // used to inform the client that the initial part of the request has been |
108 | // received and has not yet been rejected by the server. The client SHOULD |
109 | // continue by sending the remainder of the request or, if the request has |
110 | // already been completed, ignore this response. The server MUST send a |
111 | // final response after the request has been completed. |
112 | // |
113 | // See http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3 for |
114 | // detailed discussion of the use and handling of this status code. |
115 | static const int HTTP_STATUS_CONTINUE = 100; |
116 | |
117 | // 101 Switching Protocols |
118 | // |
119 | // The server understands and is willing to comply with the client's |
120 | // request, via the Upgrade message header field (section 14.42), for a |
121 | // change in the application protocol being used on this connection. The |
122 | // server will switch protocols to those defined by the response's Upgrade |
123 | // header field immediately after the empty line which terminates the 101 |
124 | // response. |
125 | // |
126 | // The protocol SHOULD be switched only when it is advantageous to do so. |
127 | // For example, switching to a newer version of HTTP is advantageous over |
128 | // older versions, and switching to a real-time, synchronous protocol might |
129 | // be advantageous when delivering resources that use such features. |
130 | static const int HTTP_STATUS_SWITCHING_PROTOCOLS = 101; |
131 | |
132 | // Successful 2xx |
133 | // This class of status code indicates that the client's request was |
134 | // successfully received, understood, and accepted. |
135 | |
136 | // 200 OK |
137 | // |
138 | // The request has succeeded. The information returned with the response is |
139 | // dependent on the method used in the request, for example: |
140 | // - GET an entity corresponding to the requested resource is sent in the |
141 | // response. |
142 | // - HEAD the entity-header fields corresponding to the requested resource |
143 | // are sent in the response without any message-body. |
144 | // - POST an entity describing or containing the result of the action; |
145 | // - TRACE an entity containing the request message as received by the end |
146 | // server. |
147 | static const int HTTP_STATUS_OK = 200; |
148 | |
149 | // 201 Created |
150 | // |
151 | // The request has been fulfilled and resulted in a new resource being |
152 | // created. The newly created resource can be referenced by the URI(s) |
153 | // returned in the entity of the response, with the most specific URI for |
154 | // the resource given by a Location header field. The response SHOULD |
155 | // include an entity containing a list of resource characteristics and |
156 | // location(s) from which the user or user agent can choose the one most |
157 | // appropriate. The entity format is specified by the media type given in |
158 | // the Content-Type header field. The origin server MUST create the resource |
159 | // before returning the 201 status code. If the action cannot be carried out |
160 | // immediately, the server SHOULD respond with 202 (Accepted) response |
161 | // instead. |
162 | // |
163 | // A 201 response MAY contain an ETag response header field indicating the |
164 | // current value of the entity tag for the requested variant just created; |
165 | // see section 14.19 |
166 | // (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19) |
167 | static const int HTTP_STATUS_CREATED = 201; |
168 | |
169 | // 202 Accepted |
170 | // |
171 | // The request has been accepted for processing, but the processing has not |
172 | // been completed. The request might or might not eventually be acted upon; |
173 | // as it might be disallowed when processing actually takes place. There is |
174 | // no facility for re-sending a status code from an asynchronous operation |
175 | // such as this. |
176 | // |
177 | // The 202 response is intentionally non-committal. Its purpose is to allow |
178 | // a server to accept a request for some other process (perhaps a |
179 | // batch-oriented process that is only run once per day) without requiring |
180 | // that the user agent's connection to the server persist until the process |
181 | // is completed. The entity returned with this response SHOULD include an |
182 | // indication of the request's current status and either a pointer to a |
183 | // status monitor or some estimate of when the user can expect the request |
184 | // to be fulfilled. |
185 | static const int HTTP_STATUS_ACCEPTED = 202; |
186 | |
187 | // 203 Non-Authoritative Information |
188 | // |
189 | // The returned metainformation in the entity-header is not the definitive |
190 | // set as available from the origin server, but is gathered from a local or |
191 | // a third-party copy. The set presented MAY be a subset or superset of the |
192 | // original version. For example, including local annotation information |
193 | // about the resource might result in a superset of the metainformation |
194 | // known by the origin server. Use of this response code is not required and |
195 | // is only appropriate when the response would otherwise be 200 (OK). |
196 | static const int HTTP_STATUS_NON_AUTHORITATIVE_INFORMATION = 203; |
197 | |
198 | // 204 No Content |
199 | // |
200 | // The server has fulfilled the request but does not need to return an |
201 | // entity-body, and might want to return updated metainformation. The |
202 | // response MAY include new or updated metainformation in the form of |
203 | // entity-headers, which if present SHOULD be associated with the requested |
204 | // variant. |
205 | // |
206 | // If the client is a user agent, it SHOULD NOT change its document view |
207 | // from that which caused the request to be sent. This response is primarily |
208 | // intended to allow input for actions to take place without causing a |
209 | // change to the user agent's active document view, although any new or |
210 | // updated metainformation SHOULD be applied to the document currently in |
211 | // the user agent's active view. |
212 | // |
213 | // The 204 response MUST NOT include a message-body, and thus is always |
214 | // terminated by the first empty line after the header fields. |
215 | static const int HTTP_STATUS_NO_CONTENT = 204; |
216 | |
217 | // 205 Reset Content |
218 | // |
219 | // The server has fulfilled the request and the user agent SHOULD reset the |
220 | // document view which caused the request to be sent. This response is |
221 | // primarily intended to allow input for actions to take place via user |
222 | // input, followed by a clearing of the form in which the input is given so |
223 | // that the user can easily initiate another input action. The response |
224 | // MUST NOT include an entity. |
225 | static const int HTTP_STATUS_RESET_CONTENT = 205; |
226 | |
227 | // 206 Partial Content |
228 | // |
229 | // The server has fulfilled the partial GET request for the resource. The |
230 | // request MUST have included a Range header field (section 14.35 |
231 | // http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35) |
232 | // indicating the desired range, and MAY have included an If-Range header |
233 | // field (section 14.27) to make the request conditional. |
234 | // |
235 | // The response MUST include the following header fields: |
236 | // - Either a Content-Range header field (section 14.16 |
237 | // http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.16) |
238 | // indicating the range included with this response, or a |
239 | // multipart/byteranges Content-Type including Content-Range fields for |
240 | // each part. If a Content-Length header field is present in the |
241 | // response, its value MUST match the actual number of OCTETs |
242 | // transmitted in the message-body. |
243 | // - Date |
244 | // - ETag and/or Content-Location, if the header would have been sent |
245 | // in a 200 response to the same request |
246 | // - Expires, Cache-Control, and/or Vary, if the field-value might |
247 | // differ from that sent in any previous response for the same |
248 | // variant |
249 | // |
250 | // If the 206 response is the result of an If-Range request that used a |
251 | // strong cache validator (see section 13.3.3 |
252 | // http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.3), |
253 | // the response SHOULD NOT include other entity-headers. If the response is |
254 | // the result of an If-Range request that used a weak validator, the |
255 | // response MUST NOT include other entity-headers; this prevents |
256 | // inconsistencies between cached entity-bodies and updated headers. |
257 | // Otherwise, the response MUST include all of the entity-headers that would |
258 | // have been returned with a 200 (OK) response to the same request. |
259 | // |
260 | // A cache MUST NOT combine a 206 response with other previously cached |
261 | // content if the ETag or Last-Modified headers do not match exactly, see |
262 | // 13.5.4 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.5.4) |
263 | // |
264 | // A cache that does not support the Range and Content-Range headers MUST |
265 | // NOT cache 206 (Partial) responses. |
266 | static const int HTTP_STATUS_PARTIAL_CONTENT = 206; |
267 | |
268 | // Redirection 3xx |
269 | // This class of status code indicates that further action needs to be |
270 | // taken by the user agent in order to fulfill the request. The action |
271 | // required MAY be carried out by the user agent without interaction with |
272 | // the user if and only if the method used in the second request is GET or |
273 | // HEAD. A client SHOULD detect infinite redirection loops, since such |
274 | // loops generate network traffic for each redirection. |
275 | |
276 | // 300 Multiple Choices |
277 | // The requested resource corresponds to any one of a set of |
278 | // representations, each with its own specific location, and agent-driven |
279 | // negotiation information |
280 | // (http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html#sec12.2) |
281 | // is being provided so that the user (or user agent) can select a preferred |
282 | // representation and redirect its request to that location. |
283 | // |
284 | // Unless it was a HEAD request, the response SHOULD include an entity |
285 | // containing a list of resource characteristics and location(s) from which |
286 | // the user or user agent can choose the one most appropriate. The entity |
287 | // format is specified by the media type given in the Content- Type header |
288 | // field. Depending upon the format and the capabilities of |
289 | // |
290 | // the user agent, selection of the most appropriate choice MAY be performed |
291 | // automatically. However, this specification does not define any standard |
292 | // for such automatic selection. |
293 | // |
294 | // If the server has a preferred choice of representation, it SHOULD include |
295 | // the specific URI for that representation in the Location field; user |
296 | // agents MAY use the Location field value for automatic redirection. This |
297 | // response is cacheable unless indicated otherwise. |
298 | static const int HTTP_STATUS_MULTIPLE_CHOICES = 300; |
299 | |
300 | // 301 Moved Permanently |
301 | // |
302 | // The requested resource has been assigned a new permanent URI and any |
303 | // future references to this resource SHOULD use one of the returned URIs. |
304 | // Clients with link editing capabilities ought to automatically re-link |
305 | // references to the Request-URI to one or more of the new references |
306 | // returned by the server, where possible. This response is cacheable |
307 | // unless indicated otherwise. |
308 | // |
309 | // The new permanent URI SHOULD be given by the Location field in the |
310 | // response. Unless the request method was HEAD, the entity of the response |
311 | // SHOULD contain a short hypertext note with a hyperlink to the new |
312 | // URI(s). |
313 | // |
314 | // If the 301 status code is received in response to a request other than |
315 | // GET or HEAD, the user agent MUST NOT automatically redirect the request |
316 | // unless it can be confirmed by the user, since this might change the |
317 | // conditions under which the request was issued. |
318 | static const int HTTP_STATUS_MOVE_PERMANENTLY = 301; |
319 | |
320 | // 302 Found |
321 | // |
322 | // The requested resource resides temporarily under a different URI. Since |
323 | // the redirection might be altered on occasion, the client SHOULD continue |
324 | // to use the Request-URI for future requests. This response is only |
325 | // cacheable if indicated by a Cache-Control or Expires header field. |
326 | // |
327 | // The temporary URI SHOULD be given by the Location field in the response. |
328 | // Unless the request method was HEAD, the entity of the response SHOULD |
329 | // contain a short hypertext note with a hyperlink to the new URI(s). |
330 | // |
331 | // If the 302 status code is received in response to a request other than |
332 | // GET or HEAD, the user agent MUST NOT automatically redirect the request |
333 | // unless it can be confirmed by the user, since this might change the |
334 | // conditions under which the request was issued. |
335 | static const int HTTP_STATUS_FOUND = 302; |
336 | |
337 | // 303 See Other |
338 | // |
339 | // The response to the request can be found under a different URI and |
340 | // SHOULD be retrieved using a GET method on that resource. This method |
341 | // exists primarily to allow the output of a POST-activated script to |
342 | // redirect the user agent to a selected resource. The new URI is not a |
343 | // substitute reference for the originally requested resource. The 303 |
344 | // response MUST NOT be cached, but the response to the second (redirected) |
345 | // request might be cacheable. |
346 | // |
347 | // The different URI SHOULD be given by the Location field in the response. |
348 | // Unless the request method was HEAD, the entity of the response SHOULD |
349 | // contain a short hypertext note with a hyperlink to the new URI(s). |
350 | static const int HTTP_STATUS_SEE_OTHER = 303; |
351 | |
352 | // 304 Not Modified |
353 | // |
354 | // If the client has performed a conditional GET request and access is |
355 | // allowed, but the document has not been modified, the server SHOULD |
356 | // respond with this status code. The 304 response MUST NOT contain a |
357 | // message-body, and thus is always terminated by the first empty line |
358 | // after the header fields. |
359 | // |
360 | // The response MUST include the following header fields: |
361 | // - Date, unless its omission is required by section 14.18.1 |
362 | // (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.18.1) |
363 | // If a clockless origin server obeys these rules, and proxies and clients |
364 | // add their own Date to any response received without one (as already |
365 | // specified by [RFC 2068], section 14.19 |
366 | // http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19), caches |
367 | // will operate correctly. |
368 | static const int HTTP_STATUS_NOT_MODIFIED = 304; |
369 | |
370 | // 305 Use Proxy |
371 | // |
372 | // The requested resource MUST be accessed through the proxy given by the |
373 | // Location field. The Location field gives the URI of the proxy. The |
374 | // recipient is expected to repeat this single request via the proxy. 305 |
375 | // responses MUST only be generated by origin servers. |
376 | // |
377 | // Note: RFC 2068 was not clear that 305 was intended to redirect a |
378 | // single request, and to be generated by origin servers only. |
379 | // Not observing these limitations has significant security |
380 | // consequences. |
381 | static const int HTTP_STATUS_USE_PROXY = 305; |
382 | |
383 | // 307 Temporary Redirect |
384 | // |
385 | // The requested resource resides temporarily under a different URI. Since |
386 | // the redirection MAY be altered on occasion, the client SHOULD continue to |
387 | // use the Request-URI for future requests. This response is only cacheable |
388 | // if indicated by a Cache-Control or Expires header field. |
389 | // |
390 | // The temporary URI SHOULD be given by the Location field in the response. |
391 | // Unless the request method was HEAD, the entity of the response SHOULD |
392 | // contain a short hypertext note with a hyperlink to the new URI(s) , since |
393 | // many pre-HTTP/1.1 user agents do not understand the 307 status. |
394 | // Therefore, the note SHOULD contain the information necessary for a user |
395 | // to repeat the original request on the new URI. |
396 | // |
397 | // If the 307 status code is received in response to a request other than |
398 | // GET or HEAD, the user agent MUST NOT automatically redirect the request |
399 | // unless it can be confirmed by the user, since this might change the |
400 | // conditions under which the request was issued. |
401 | static const int HTTP_STATUS_TEMPORARY_REDIRECT = 307; |
402 | |
403 | // Client Error 4xx |
404 | // The 4xx class of status code is intended for cases in which the client |
405 | // seems to have erred. Except when responding to a HEAD request, the |
406 | // server SHOULD include an entity containing an explanation of the error |
407 | // situation, and whether it is a temporary or permanent condition. These |
408 | // status codes are applicable to any request method. User agents SHOULD |
409 | // display any included entity to the user. |
410 | // |
411 | // If the client is sending data, a server implementation using TCP SHOULD |
412 | // be careful to ensure that the client acknowledges receipt of the |
413 | // packet(s) containing the response, before the server closes the input |
414 | // connection. If the client continues sending data to the server after the |
415 | // close, the server's TCP stack will send a reset packet to the client; |
416 | // which may erase the client's unacknowledged input buffers before they |
417 | // can be read and interpreted by the HTTP application. |
418 | |
419 | // 400 Bad Request |
420 | // The request could not be understood by the server due to malformed |
421 | // syntax. The client SHOULD NOT repeat the request without modifications. |
422 | static const int HTTP_STATUS_BAD_REQUEST = 400; |
423 | |
424 | // 401 Unauthorized |
425 | // |
426 | // The request requires user authentication. The response MUST include a |
427 | // WWW-Authenticate header field containing a challenge |
428 | // applicable to the requested resource. The client MAY repeat the request |
429 | // with a suitable Authorization header field. If the request |
430 | // already included Authorization credentials, then the 401 response |
431 | // indicates that authorization has been refused for those credentials. If |
432 | // the 401 response contains the same challenge as the prior response, and |
433 | // the user agent has already attempted authentication at least once, then |
434 | // the user SHOULD be presented the entity that was given in the response; |
435 | // since that entity might include relevant diagnostic information. HTTP |
436 | // access authentication is explained in "HTTP Authentication: Basic and |
437 | // Digest Access Authentication" (http://www.ietf.org/rfc/rfc2617.txt) |
438 | static const int HTTP_STATUS_UNAUTHORIZED = 401; |
439 | |
440 | // 402 Payment Required |
441 | // |
442 | // This code is reserved for future use. |
443 | static const int HTTP_STATUS_PAYMENT_REQUIRED = 402; |
444 | |
445 | // 403 Forbidden |
446 | // |
447 | // The server understood the request, but is refusing to fulfill it. |
448 | // Authorization will not help and the request SHOULD NOT be repeated. If |
449 | // the request method was not HEAD and the server wishes to make public why |
450 | // the request has not been fulfilled, it SHOULD describe the reason for |
451 | // the refusal in the entity. If the server does not wish to make this |
452 | // information available to the client, the status code 404 (Not Found) can |
453 | // be used instead. |
454 | static const int HTTP_STATUS_FORBIDDEN = 403; |
455 | |
456 | // 404 Not Found |
457 | // |
458 | // The server has not found anything matching the Request-URI. No indication |
459 | // is given of whether the condition is temporary or permanent. The 410 |
460 | // (Gone) status code SHOULD be used if the server knows, through some |
461 | // internally configurable mechanism, that an old resource is permanently |
462 | // unavailable and has no forwarding address. This status code is commonly |
463 | // used when the server does not wish to reveal exactly why the request has |
464 | // been refused, or when no other response is applicable. |
465 | static const int HTTP_STATUS_NOT_FOUND = 404; |
466 | |
467 | // 405 Method Not Allowed |
468 | // |
469 | // The method specified in the Request-Line is not allowed for the resource |
470 | // identified by the Request-URI. The response MUST include an Allow header |
471 | // containing a list of valid methods for the requested resource. |
472 | static const int HTTP_STATUS_METHOD_NOT_ALLOWED = 405; |
473 | |
474 | // 406 Not Acceptable |
475 | // |
476 | // The resource identified by the request is only capable of generating |
477 | // response entities which have content characteristics not acceptable |
478 | // according to the accept headers sent in the request. |
479 | // |
480 | // Unless it was a HEAD request, the response SHOULD include an entity |
481 | // containing a list of available entity characteristics and location(s) |
482 | // from which the user or user agent can choose the one most appropriate. |
483 | // The entity format is specified by the media type given in the |
484 | // Content-Type header field. Depending upon the format and the |
485 | // capabilities of the user agent, selection of the most appropriate choice |
486 | // MAY be performed automatically. However, this specification does not |
487 | // define any standard for such automatic selection. |
488 | static const int HTTP_STATUS_NOT_ACCEPTABLE = 406; |
489 | |
490 | // 407 Proxy Authentication Required |
491 | // This code is similar to 401 (Unauthorized), but indicates that the client |
492 | // must first authenticate itself with the proxy. The proxy MUST return a |
493 | // Proxy-Authenticate header field containing a challenge |
494 | // applicable to the proxy for the requested resource. The client MAY repeat |
495 | // the request with a suitable Proxy-Authorization header field. |
496 | // HTTP access authentication is explained in "HTTP Authentication: |
497 | // Basic and Digest Access Authentication" |
498 | static const int HTTP_STATUS_PROXY_AUTHENTICATION_REQUIRED = 407; |
499 | |
500 | // 408 Request Timeout |
501 | // |
502 | // The client did not produce a request within the time that the server was |
503 | // prepared to wait. The client MAY repeat the request without modifications |
504 | // at any later time. |
505 | static const int HTTP_STATUS_REQUEST_TIMEOUT = 408; |
506 | |
507 | // 409 Conflict |
508 | // |
509 | // The request could not be completed due to a conflict with the current |
510 | // state of the resource. This code is only allowed in situations where it |
511 | // is expected that the user might be able to resolve the conflict and |
512 | // resubmit the request. The response body SHOULD include enough information |
513 | // for the user to recognize the source of the conflict. Ideally, the |
514 | // response entity would include enough information for the user or user |
515 | // agent to fix the problem; however, that might not be possible and is not |
516 | // required. |
517 | // |
518 | // Conflicts are most likely to occur in response to a PUT request. For |
519 | // example, if versioning were being used and the entity being PUT included |
520 | // changes to a resource which conflict with those made by an earlier |
521 | // (third-party) request, the server might use the 409 response to indicate |
522 | // that it can't complete the request. In this case, the response entity |
523 | // would likely contain a list of the differences between the two versions |
524 | // in a format defined by the response Content-Type. |
525 | static const int HTTP_STATUS_CONFLICT = 409; |
526 | |
527 | // 410 Gone |
528 | // |
529 | // The requested resource is no longer available at the server and no |
530 | // forwarding address is known. This condition is expected to be considered |
531 | // permanent. Clients with link editing capabilities SHOULD delete |
532 | // references to the Request-URI after user approval. If the server does not |
533 | // know, or has no facility to determine, whether or not the condition is |
534 | // permanent, the status code 404 (Not Found) SHOULD be used instead. This |
535 | // response is cacheable unless indicated otherwise. |
536 | // |
537 | // The 410 response is primarily intended to assist the task of web |
538 | // maintenance by notifying the recipient that the resource is intentionally |
539 | // unavailable and that the server owners desire that remote links to that |
540 | // resource be removed. Such an event is common for limited-time; |
541 | // promotional services and for resources belonging to individuals no longer |
542 | // working at the server's site. It is not necessary to mark all permanently |
543 | // unavailable resources as "gone" or to keep the mark for any length of |
544 | // time -- that is left to the discretion of the server owner. |
545 | static const int HTTP_STATUS_GONE = 410; |
546 | |
547 | // 411 Length Required |
548 | // |
549 | // The server refuses to accept the request without a defined |
550 | // Content-Length. The client MAY repeat the request if it adds a valid |
551 | // Content-Length header field containing the length of the message-body in |
552 | // the request message. |
553 | static const int HTTP_STATUS_LENGTH_REQUIRED = 411; |
554 | |
555 | // 412 Precondition Failed |
556 | // |
557 | // The precondition given in one or more of the request-header fields |
558 | // evaluated to false when it was tested on the server. This response code |
559 | // allows the client to place preconditions on the current resource |
560 | // metainformation (header field data) and thus prevent the requested method |
561 | // from being applied to a resource other than the one intended. |
562 | static const int HTTP_STATUS_PRECONDITION_FAILED = 412; |
563 | |
564 | // 413 Request Entity Too Large |
565 | // |
566 | // The server is refusing to process a request because the request entity is |
567 | // larger than the server is willing or able to process. The server MAY |
568 | // close the connection to prevent the client from continuing the request. |
569 | // |
570 | // If the condition is temporary, the server SHOULD include a Retry-After |
571 | // header field to indicate that it is temporary and after what time the |
572 | // client MAY try again. |
573 | static const int HTTP_STATUS_REQUEST_ENTITY_TOO_LARGE = 413; |
574 | |
575 | // 414 Request-URI Too Long |
576 | // |
577 | // The server is refusing to service the request because the Request-URI is |
578 | // longer than the server is willing to interpret. This rare condition is |
579 | // only likely to occur when a client has improperly converted a POST |
580 | // request to a GET request with long query information, when the client has |
581 | // descended into a URI "black hole" of redirection (e.g., a redirected URI |
582 | // prefix that points to a suffix of itself), or when the server is under |
583 | // attack by a client attempting to exploit security holes present in some |
584 | // servers using fixed-length buffers for reading or manipulating the |
585 | // Request-URI. |
586 | static const int HTTP_STATUS_REQUEST_URI_TOO_LARG = 414; |
587 | |
588 | // 415 Unsupported Media Type |
589 | // |
590 | // The server is refusing to service the request because the entity of the |
591 | // request is in a format not supported by the requested resource for the |
592 | // requested method. |
593 | static const int HTTP_STATUS_UNSUPPORTED_MEDIA_TYPE = 415; |
594 | |
595 | // 416 Requested Range Not Satisfiable |
596 | // |
597 | // A server SHOULD return a response with this status code if a request |
598 | // included a Range request-header field, and none of the |
599 | // range-specifier values in this field overlap the current extent of the |
600 | // selected resource, and the request did not include an If-Range |
601 | // request-header field. (For byte-ranges, this means that the |
602 | // first-byte-pos of all of the byte-range-spec values were greater than the |
603 | // current length of the selected resource.) |
604 | // |
605 | // When this status code is returned for a byte-range request, the response |
606 | // SHOULD include a Content-Range entity-header field specifying the current |
607 | // length of the selected resource. This response MUST |
608 | // NOT use the multipart/byteranges content-type. |
609 | static const int HTTP_STATUS_REQUEST_RANGE_NOT_SATISFIABLE = 416; |
610 | |
611 | // 417 Expectation Failed |
612 | // |
613 | // The expectation given in an Expect request-header field (see section |
614 | // 14.20 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.20) |
615 | // could not be met by this server, or, if the server is a proxy, the |
616 | // server has unambiguous evidence that the request could not be met by the |
617 | // next-hop server. |
618 | static const int HTTP_STATUS_EXPECTATION_FAILED = 417; |
619 | |
620 | // Server Error 5xx |
621 | // |
622 | // Response status codes beginning with the digit "5" indicate cases in |
623 | // which the server is aware that it has erred or is incapable of performing |
624 | // the request. Except when responding to a HEAD request, the server SHOULD |
625 | // include an entity containing an explanation of the error situation, and |
626 | // whether it is a temporary or permanent condition. User agents SHOULD |
627 | // display any included entity to the user. These response codes are |
628 | // applicable to any request method. |
629 | |
630 | // 500 Internal Server Error |
631 | // |
632 | // The server encountered an unexpected condition which prevented it from |
633 | // fulfilling the request. |
634 | static const int HTTP_STATUS_INTERNAL_SERVER_ERROR = 500; |
635 | |
636 | // 501 Not Implemented |
637 | // |
638 | // The server does not support the functionality required to fulfill the |
639 | // request. This is the appropriate response when the server does not |
640 | // recognize the request method and is not capable of supporting it for any |
641 | // resource. |
642 | static const int HTTP_STATUS_NOT_IMPLEMENTED = 501; |
643 | |
644 | // 502 Bad Gateway |
645 | // |
646 | // The server, while acting as a gateway or proxy, received an invalid |
647 | // response from the upstream server it accessed in attempting to fulfill |
648 | // the request. |
649 | static const int HTTP_STATUS_BAD_GATEWAY = 502; |
650 | |
651 | // 503 Service Unavailable |
652 | // |
653 | // The server is currently unable to handle the request due to a temporary |
654 | // overloading or maintenance of the server. The implication is that this is |
655 | // a temporary condition which will be alleviated after some delay. If |
656 | // known, the length of the delay MAY be indicated in a Retry-After header. |
657 | // If no Retry-After is given, the client SHOULD handle the response as it |
658 | // would for a 500 response. |
659 | static const int HTTP_STATUS_SERVICE_UNAVAILABLE = 503; |
660 | |
661 | // 504 Gateway Timeout |
662 | // |
663 | // The server, while acting as a gateway or proxy, did not receive a timely |
664 | // response from the upstream server specified by the URI (e.g. HTTP, FTP; |
665 | // LDAP) or some other auxiliary server (e.g. DNS) it needed to access in |
666 | // attempting to complete the request. |
667 | static const int HTTP_STATUS_GATEWAY_TIMEOUT = 504; |
668 | |
669 | // 505 HTTP Version Not Supported |
670 | // |
671 | // The server does not support, or refuses to support, the HTTP protocol |
672 | // version that was used in the request message. The server is indicating |
673 | // that it is unable or unwilling to complete the request using the same |
674 | // major version as the client, as described in section 3.1, other than with |
675 | // this error message. The response SHOULD contain an entity describing why |
676 | // that version is not supported and what other protocols are supported by |
677 | // that server. |
678 | static const int HTTP_STATUS_VERSION_NOT_SUPPORTED = 505; |
679 | |
680 | } // namespace brpc |
681 | |
682 | |
683 | #endif //BRPC_HTTP_STATUS_CODE_H |
684 | |