1.3. HTTP response
- An HTTP response looks very much like an HTTP request. Both are called HTTP
- messages. Let's consider this HTTP response :
-
- Line Contents
- number
- 1 HTTP/1.1 200 OK
- 2 Content-length: 350
- 3 Content-Type: text/html
-
- As a special case, HTTP supports so called "Informational responses" as status
- codes 1xx. These messages are special in that they don't convey any part of the
- response, they're just used as sort of a signaling message to ask a client to
- continue to post its request for instance. In the case of a status 100 response
- the requested information will be carried by the next non-100 response message
- following the informational one. This implies that multiple responses may be
- sent to a single request, and that this only works when keep-alive is enabled
- (1xx messages are HTTP/1.1 only). HAProxy handles these messages and is able to
- correctly forward and skip them, and only process the next non-100 response. As
- such, these messages are neither logged nor transformed, unless explicitly
- state otherwise. Status 101 messages indicate that the protocol is changing
- over the same connection and that haproxy must switch to tunnel mode, just as
- if a CONNECT had occurred. Then the Upgrade header would contain additional
- information about the type of protocol the connection is switching to.
1.3.1. The response line
- Line 1 is the "response line". It is always composed of 3 fields :
-
- - a version tag : HTTP/1.1
- - a status code : 200
- - a reason : OK
-
- The status code is always 3-digit. The first digit indicates a general status :
- - 1xx = informational message to be skipped (e.g. 100, 101)
- - 2xx = OK, content is following (e.g. 200, 206)
- - 3xx = OK, no content following (e.g. 302, 304)
- - 4xx = error caused by the client (e.g. 401, 403, 404)
- - 5xx = error caused by the server (e.g. 500, 502, 503)
-
- Please refer to RFC7231 for the detailed meaning of all such codes. The
- "reason" field is just a hint, but is not parsed by clients. Anything can be
- found there, but it's a common practice to respect the well-established
- messages. It can be composed of one or multiple words, such as "OK", "Found",
- or "Authentication Required".
-
- HAProxy may emit the following status codes by itself :
-
- Code When / reason
- 200 access to stats page, and when replying to monitoring requests
- 301 when performing a redirection, depending on the configured code
- 302 when performing a redirection, depending on the configured code
- 303 when performing a redirection, depending on the configured code
- 307 when performing a redirection, depending on the configured code
- 308 when performing a redirection, depending on the configured code
- 400 for an invalid or too large request
- 401 when an authentication is required to perform the action (when
- accessing the stats page)
- 403 when a request is forbidden by a "block" ACL or "reqdeny" filter
- 408 when the request timeout strikes before the request is complete
- 500 when haproxy encounters an unrecoverable internal error, such as a
- memory allocation failure, which should never happen
- 502 when the server returns an empty, invalid or incomplete response, or
- when an "rspdeny" filter blocks the response.
- 503 when no server was available to handle the request, or in response to
- monitoring requests which match the "monitor fail" condition
- 504 when the response timeout strikes before the server responds
-
- The error 4xx and 5xx codes above may be customized (see "errorloc" in section
- 4.2).
1.3.2. The response headers
- Response headers work exactly like request headers, and as such, HAProxy uses
- the same parsing function for both. Please refer to paragraph 1.2.2 for more
- details.