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
23namespace 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.
79const char *HttpReasonPhrase(int status_code);
80
81// Convert brpc error code to related status code.
82int 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.
115static 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.
130static 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.
147static 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)
167static 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.
185static 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).
196static 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.
215static 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.
225static 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.
266static 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.
298static 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.
318static 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.
335static 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).
350static 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.
368static 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.
381static 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.
401static 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.
422static 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)
438static const int HTTP_STATUS_UNAUTHORIZED = 401;
439
440// 402 Payment Required
441//
442// This code is reserved for future use.
443static 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.
454static 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.
465static 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.
472static 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.
488static 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"
498static 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.
505static 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.
525static 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.
545static 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.
553static 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.
562static 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.
573static 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.
586static 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.
593static 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.
609static 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.
618static 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.
634static 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.
642static 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.
649static 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.
659static 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.
667static 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.
678static const int HTTP_STATUS_VERSION_NOT_SUPPORTED = 505;
679
680} // namespace brpc
681
682
683#endif //BRPC_HTTP_STATUS_CODE_H
684