Request Header

Limits

• Target URI: 8192 bytes (otherwise returns 414: URI Too Long).
• Header fields: single or total field(s) cannot exceed 8192 bytes (otherwise returns 431: Request Header Fields Too Large).
• Payload body: default 1MB (otherwise returns 413: Payload Too Large). Can be edited through configuration file using client_max_body_size directive.
• Chunk extensions: 8192 bytes (otherwise returns 413: Payload Too Large).

Request line

• Format: begins with a method token, followed by a single space (SP), the request-target, another single space (SP), the protocol version, and ends with CRLF.
• Line breaks: for robustness, the parser accepts both CRLF and just LF.
• Error checking: requests not matching the grammar defined in RFC 7230 are not autocorrected and will return 400: Bad Request error.

Method

• Accepted methods: GET, POST, DELETE
• Returns 501: Not Implemented error if method passed is not one of these.

Request target

• Server only accepts origin-form URIs.
• If the target URI's path component is empty, the client MUST send "/" as the path within the origin-form of request-target. A Host header field is also sent.
• Percent-encoded octets are decoded only once to avoid misinterpretation.
  • This is done after a character triplet consisting of "%" followed by two hexadecimal digits is parsed.
  • Lower and uppercase hexadecimal digits are treated the same in the context of URIs, so the parser normalizes them to uppercase.
• Queries in target URI:
  • The form content is only encoded in the URL's query string when the form submission method is GET.
  • The same encoding is used by default when the submission method is POST, but the result is submitted as the HTTP request body rather than being included in a modified URL.

Protocol

• Server only accepts HTTP/1.1
• Returns 505: HTTP Version Not Supported otherwise.

Header fields

• Format: each header field consists of a case-insensitive field name followed by a colon (":"), optional leading whitespace, the field value, optional trailing whitespace, and ends with CRLF.
• Parsing: request parser reads fields until an empty line is encountered, then validates header fields, and finally it determines if a message body is expected.
• Reoccurring header names are not allowed unless comma-separated list values are allowed for that header (e.g. Accept-Language) or if it is a known exception (Set-Cookie).
• Error checking: if encountered, returns 400: Bad Request
  • No whitespace is allowed between the header field-name and colon.
  • Line folding (multi-line values indicated by beginning space or horizontal tab) is not allowed except within the message/http media type.

Content-Encoding

• Not handled at all by our webserver. Throws 415: Unsupported Media Type if defined in request header.

Expect

• Only 100-continue is accepted. Else returns 417: Expectation Failed.
• Our webserver only sends a 100 (Continue) response if request framing indicates a message is expected but nothing has been received yet.

Host

• Error checking: missing/multiple Host header fields or with invalid field-value returns 400: Bad Request.

Content-Length

• A sender MUST NOT send a Content-Length header field in any message that contains a Transfer-Encoding header field.
• Error checking: the following cases return 400: Bad Request and close the connection
  • multiple Content-Length header fields having differing field-values
  • a single Content-Length header field having an invalid value.
• Multiple Content-Length header fields with same field-values OR single Content-Length header with multiple identical values is rejected as invalid.
• As allowed by RFC 7230 Section 3.3.3, our webserver requires Content-Length header if a message body is present, otherwise it returns 411: Length Required.
• Note: GET and DELETE can only have Content-Length of 0. POST may have other values (including 0 for empty payload). The first 2 methods have no defined payload semantics and given the potential of message bodies being used in request smuggling attacks, our webserver rejects it (also see updated specification in RFC 9110).

Transfer-Encoding

• Error checking: if the chunked transfer coding is not the final encoding, the server returns 400: Bad Request status code and then closes the connection.
• Only chunked Transfer-Encoding is accepted. Else returns 501: Not Implemented.
• Note: Transfer-Encoding is only accepted with POST method. See last point in Content-Length above for explanation.

Message body

• Read as a stream until an amount of octets equal to the message body length is read or the connection is closed.
• Line breaks: if terminating the request message body with a line-ending is desired, then the user agent MUST count the terminating CRLF octets as part of the message body length.