RFC7230

Section 1 & 2

URIs are case-insensitive up until the ‘/’ begining with it it is to be treated as a absolute path
User-Agents (UA) are not neccesarily human controlled
A client can also be a server to another device
If a authoritive name is used in the URI it is a imperative to use DNS
If no port is given for http TCP:80 is used
If no port is given for https TCP:443 is used
The first line of a HTTP-Response from the server is ALWAYS the version number e.g “HTTP-Version = HTTP/1.1”
There are three types of intermediaries

• Proxy Selected by the Client forwards the request
• Gateway (Reverse proxy) Acts as the origin server. Client’s don’t know it’s an intermediary (load balancer)
• Tunnel: A blind relay between two connections where http is not interpreted
  A cache may be used by intermediaries to store responses to reduce network hops and latency

Section 3

The first line of the header may not include a leading whitespace
header field-names are case-insensitive and are followed by a “:” a Space (SP) and then the fiel-value and optionally a trailing whitespace.
The first line of a response is always the status line. Which consists of the Protocool version a space the status code another SPace optionally a reason text and then a CRLF
status-line = HTTP-version SP status-code SP reason-phrase CRLF
the status code is a 3-Digit integer
Client’s should ignore the reason-phrase.
It is recommended that all http senders and recipients support at a minimum request-lines of 8000 octets
There is no apparent order in which header-fields should occur.
However fields must be unique: Duplicate header names are allowed if their values can be combined into a comma-seperated list. An exeption to this is the set-cookies header-field
If a message does not have a Transfer-Encoding header a Content-Length header field can provide the anticipated size as a decimal number of octets. If the Transfer-Encoding field is set the Content-Length field MUST NOT be sent
If a message contains both Transfer-Encoding and Content-Length the Content-Length MUST be ignored.
To prevent Smuggling a server should reject such a message with a 400 Bad Request.
If neither Transfer-Encoding nor Content-Length is present, the body legth is determined by the server closing the connection (EOF)
Line folding (splitting a single header over multiple lines using spaces) is deprecated. Receivers should reject messages containing it.

Section 4

The transfer-coding field can have one of four values

• chunked
• compress
• deflate
• gzip
  Transfercoding indicate a encoding transformation that has been, can be, or might need to be applied to the payload body in order to ensure a safe transport.
  All transfer-coding names are case-insensitive.

Chunked Transfer Coding

The chunked transfer coding wraps the payload body in order to transfer it in chunks
each chunk contains it’s own size indicator and optionally a trailer containing header field.
Chunked content enables content streams of unknown size to be transferred. which enables the sender to retain a connection persistence and the recipient to know when it has received the entire message.

chunked-body    =   *chunk
                    last-chunk
                    trailer-part
                    CRLF

chunk           =   chunk-size [ chunk-ext ] CRLF
                    chunk-data CRLF
chunk-size      =   1*HEXDIG
last-chunk      =   1*("0") [ chunk-ext ] CRLF

chunk-data      =   1*OCTET ; a sequence of chunk-size octets

A recipient must be able to parse and decode the chunked transfer coding.

length := 0
read chunk-size, chunk-ext (if any), and CRLF
while (chunk-size > 0) {
    read chunk-data and CRLF
    append chunk-data to decoded-body
    length := length + chunk-size
    read chunk-size, chunk-ext (if any), and CRLF
}
read trailer field
while (trailer field is not empty) {
    if (trailer field is allowed to be sent in a trailer) {
        append trailer field to existing header fields
    }
    read trailer-field
}
Content-Length := length
Remove "chunked" from Transfer-Encoding
Remove Trailer from existing header fields

5 Message Routing

Request message routing is determinde by the client based on the target resource, proxy configuration and establishment or reuse of an inbound connection.
Communication is initiated by the UA for a Purpose. said purpose is a combination of request semantics Defined in RFC7231 and a target resource where to apply those emantics.