Skip to content

Rules

Jump to bottom
Kaaldra edited this page May 5, 2023 · 12 revisions

Structure

Request :

GET /toto.html HTTP/1.1
<headers>

Response :

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: <content_length>
<message_body>

Bonne pratique : envoyer les éléments de réponse les uns après les autres dès qu'on les a.

Exemple : envoyer HTTP/1.1 200 OK avant de savoir qu'on doit envoyer Content-Type: text/html

Request line

Method

RFC 9110 9.3

A server that receives a method longer than any that it implements SHOULD respond with a 501 (Not Implemented) status code. An origin server that receives a request method that is unrecognized or not implemented SHOULD respond with the 501 (Not Implemented) status code.

GET

Content received in a GET request :

  • has no generally defined semantics
  • cannot alter the meaning or target of the request
  • might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]).

Rules :

  • A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.
  • An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.

HEAD

A payload within a HEAD request message has no defined semantics. Sending a payload body on a HEAD request might cause some existing implementations to reject the request.

POST

The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.

Request-target

RFC 9110 7.1

Usual case :

  • The "request target" (parsed target URI components), are sent within the message control data and the Host header field (Section 7.2).

Two unusual cases for which the request target components are in a method-specific form. These forms MUST NOT be used with other methods :

  • CONNECT (Section 9.3.6) : the request target is the host name and port number of the tunnel destination, separated by a colon.
  • OPTIONS (Section 9.3.7) : the request target can be a single asterisk ("*").

Target reconstruction : A server reconstructs the target URI from the received components in accordance with their local configuration and incoming connection context. For HTTP/1.1, see Section 3.3 of RFC9112

RFC9112 3.3

  • The target URI is the request-target, the server will parse the URI into its generic components for evaluation.
  • Reconstructing the client's target URI is only half of the process for identifying a target resource. The other half is determining whether that target URI identifies a resource for which the server is willing and able to send a response, as defined in Section 7.4 of RFC9110.

Normalisation de la request-taget conformement à la rfc3986.

RFC3986

Section 2.1 - Percent encoding :

  • Percent-encoding is used to represent a data octet in a component when that octet's corresponding character is
    • outside the allowed set
    • being used as a delimiter of, or within, the component.
  • A percent-encoded octet is encoded as a character triplet, consisting of the percent character "%" followed by the two hexadecimal digits representing that octet's numeric value.
  • For example, %20 is the percent-encoding for the binary octet 00100000, which in US-ASCII corresponds to the space character (SP).
  • Section 2.4 describes when percent-encoding and decoding is applied. 
      pct-encoded = "%" HEXDIG HEXDIG
    • The uppercase hexadecimal digits 'A' -> 'F' are equivalent to the lowercase digits 'a' -> 'f', respectively.
    • If two URIs differ only in the case of hexadecimal digits used in percent-encoded octets, they are equivalent.
    • For consistency, URI producers and normalizers should use uppercase hexadecimal digits for all percent-encodings.

Section 5.2.4 - Dot segment removal :

  • Accept parent folder references (..) only if the references don't go further up than the root of the server.
  • A detailed description of the algorithm is given in this section.

HTTP-version

Accept HTTP/1.0 and 1.1

  • HTTP/1.1 A client MUST send a Host header field If the target URI includes an authority component, then a client MUST send a field value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter If the authority component is missing or undefined for the target URI, then a client MUST send a Host header field with an empty field value. A server MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than one Host header field line or a Host header field with an invalid field value.

  • HTTP/1.0 A server or client that receives an HTTP/1.0 message containing a Transfer-Encoding header field MUST treat the message as if the framing is faulty, even if a Content-Length is present, and close the connection after processing the message

Headers

See RFC9112

  • Transfer-Encoding-header [rfc 9110 10.1.4 et rfc 9112 7] (ancien:[rfc 7230 – 4])

    • headers must contain a transfer-encoding field with the value chunked if no content-length header.
    • A recipient MUST be able to parse the chunked transfer coding
    • A sender MUST NOT apply the chunked transfer coding more than once to a message body
    • If any transfer coding other than chunked is applied to a request's content, the sender MUST apply chunked as the final transfer coding to ensure that the message is properly framed
    • If any transfer coding other than chunked is applied to a response's content, the sender MUST either apply chunked as the final transfer coding or terminate the message by closing the connection
    • A server that receives a request message with a transfer coding it does not understand SHOULD respond with 501 (Not Implemented).
    • A server MUST NOT send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1
    • A server MAY reject a request that contains both Content-Length and Transfer-Encoding or process such a request in accordance with the Transfer-Encoding alone.
    • Regardless, the server MUST close the connection after responding to such a request to avoid the potential attacks.

  • Cookie-header / [rfc 6265]

    • When the user agent generates an HTTP request, the user agent MUST NOT attach more than one Cookie header field.
    • A user agent MAY omit the Cookie header in its entirety.

  • Referer-header [rfc 9110 10.1.3] (ancien:[rfc 7231 – 5.5.2])

    • A user agent MUST NOT include the fragment and userinfo components of the URI reference , if any, when generating the Referer field value
    • If the target URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard, or an entry within the user's bookmarks/favorites), the user agent MUST either exclude the Referer header field or send it with a value of "about:blank".
    • A user agent MUST NOT send a Referer header field in an unsecured HTTP request if the referring resource was accessed with a secure protocol

  • User-Agent-header [rfc 9110 10.1.5] (ancien:[rfc7231 -5.5.3])

    • User-Agent = product *( RWS ( product / comment ) )
    • A user agent SHOULD send a User-Agent header field in each request unless specifically configured not to do so.
    • A sender MUST NOT generate advertising or other nonessential information within the product identifier

  • Accept-header [rfc 9110 12.5.1] (ancien:[rfc7231 – 5.3.2])

    • Accept = #( media-range [ weight ] )
    • Senders using weights SHOULD send "q" last (after all mediarange parameters).
    • Recipients SHOULD process any parameter named "q" as weight, regardless of parameter ordering.

  • Accept-Encoding-header [rfc 9110 12.5.3] (ancien:[rfc 7231 – 5.3.4])

  • Content-Length-header [rfc 9110 8.6] (ancien:[rfc7230 – 3.3.2 et 3.3.3])

    • Content-Length = 1*DIGIT
    • headers must contain a content-length field, or see Transfer-enconding-header
    • A user agent SHOULD NOT send a Content-Length header field when the request message does not contain content and the method semantics do not anticipate such data.
    • A server MAY send a Content-Length header field in a response to a HEAD request ; a server MUST NOT send Content-Length in such a response unless its field value equals the decimal number of octets that would have been sent in the content of a response if the same request had used the GET method.
    • A server MAY send a Content-Length header field in a 304 (Not Modified) response to a conditional GET request ; a server MUST NOT send Content-Length in such a response unless its field value equals the decimal number of octets that would have been sent in the content of a 200 (OK) response to the same request.
    • A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content)
    • Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of content, a recipient MUST anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows or precision loss due to integer conversion
    • A sender MUST NOT forward a message with a Content-Length header field value that is known to be incorrect.
    • Likewise, a sender MUST NOT forward a message with a Content-Length header field value that does not match the ABNF above, with one exception: a recipient of a Content-Length header field value consisting of the same decimal value repeated as a comma-separated list (e.g, "ContentLength: 42, 42") MAY either reject the message as invalid or replace that invalid field value with a single instance of the decimal value, since this likely indicates that a duplicate was generated or combined by an upstream message processor.

  • Host-header [rfc 9110 7.2] (ancien:[rfc7230 – 5.3 et 5.4])

    • Host = uri-host [ ":" port ]
    • A user agent MUST generate a Host header field in a request unless it sends that information as an ":authority" pseudo-header field
    • A user agent that sends Host send it as the first field in the header section of a request.

  • Connection-header [rfc 9110 7.6.1] (ancien:[rfc7230 – 6])

    • Connection = #connection-option
    • When a field aside from Connection is used to supply control information for or about the current connection, the sender MUST list the corresponding field name within the Connection header field
    • Intermediaries MUST parse a received Connection header field before a message is forwarded and, for each connection-option in this field, remove any header or trailer field(s) from the message with the same name as the connection-option, and then remove the Connection header field itself
    • Furthermore, intermediaries SHOULD remove or replace fields that are known to require removal before forwarding, whether or not they appear as a connection-option, after applying those fields' semantics. This includes but is not limited to: (Proxy-Connection, Keep-Alive, TE, Upgrade), Transfer-Encoding
    • A sender MUST NOT send a connection option corresponding to a field that is intended for all recipients of the content
Clone this wiki locally