1.3. HTTP response

  1. An HTTP response looks very much like an HTTP request. Both are called HTTP
  2. messages. Let's consider this HTTP response :
  3.  
  4. Line Contents
  5. number
  6. 1 HTTP/1.1 200 OK
  7. 2 Content-length: 350
  8. 3 Content-Type: text/html
  9.  
  10. As a special case, HTTP supports so called "Informational responses" as status
  11. codes 1xx. These messages are special in that they don't convey any part of the
  12. response, they're just used as sort of a signaling message to ask a client to
  13. continue to post its request for instance. In the case of a status 100 response
  14. the requested information will be carried by the next non-100 response message
  15. following the informational one. This implies that multiple responses may be
  16. sent to a single request, and that this only works when keep-alive is enabled
  17. (1xx messages are HTTP/1.1 only). HAProxy handles these messages and is able to
  18. correctly forward and skip them, and only process the next non-100 response. As
  19. such, these messages are neither logged nor transformed, unless explicitly
  20. state otherwise. Status 101 messages indicate that the protocol is changing
  21. over the same connection and that haproxy must switch to tunnel mode, just as
  22. if a CONNECT had occurred. Then the Upgrade header would contain additional
  23. information about the type of protocol the connection is switching to.

1.3.1. The response line

  1. Line 1 is the "response line". It is always composed of 3 fields :
  2.  
  3. - a version tag : HTTP/1.1
  4. - a status code : 200
  5. - a reason : OK
  6.  
  7. The status code is always 3-digit. The first digit indicates a general status :
  8. - 1xx = informational message to be skipped (e.g. 100, 101)
  9. - 2xx = OK, content is following (e.g. 200, 206)
  10. - 3xx = OK, no content following (e.g. 302, 304)
  11. - 4xx = error caused by the client (e.g. 401, 403, 404)
  12. - 5xx = error caused by the server (e.g. 500, 502, 503)
  13.  
  14. Please refer to RFC7231 for the detailed meaning of all such codes. The
  15. "reason" field is just a hint, but is not parsed by clients. Anything can be
  16. found there, but it's a common practice to respect the well-established
  17. messages. It can be composed of one or multiple words, such as "OK", "Found",
  18. or "Authentication Required".
  19.  
  20. HAProxy may emit the following status codes by itself :
  21.  
  22. Code When / reason
  23. 200 access to stats page, and when replying to monitoring requests
  24. 301 when performing a redirection, depending on the configured code
  25. 302 when performing a redirection, depending on the configured code
  26. 303 when performing a redirection, depending on the configured code
  27. 307 when performing a redirection, depending on the configured code
  28. 308 when performing a redirection, depending on the configured code
  29. 400 for an invalid or too large request
  30. 401 when an authentication is required to perform the action (when
  31. accessing the stats page)
  32. 403 when a request is forbidden by a "block" ACL or "reqdeny" filter
  33. 408 when the request timeout strikes before the request is complete
  34. 500 when haproxy encounters an unrecoverable internal error, such as a
  35. memory allocation failure, which should never happen
  36. 502 when the server returns an empty, invalid or incomplete response, or
  37. when an "rspdeny" filter blocks the response.
  38. 503 when no server was available to handle the request, or in response to
  39. monitoring requests which match the "monitor fail" condition
  40. 504 when the response timeout strikes before the server responds
  41.  
  42. The error 4xx and 5xx codes above may be customized (see "errorloc" in section
  43. 4.2).

1.3.2. The response headers

  1. Response headers work exactly like request headers, and as such, HAProxy uses
  2. the same parsing function for both. Please refer to paragraph 1.2.2 for more
  3. details.