diff options
Diffstat (limited to 'doc/src/specs/rfc7230_server.ezdoc')
| -rw-r--r-- | doc/src/specs/rfc7230_server.ezdoc | 891 |
1 files changed, 891 insertions, 0 deletions
diff --git a/doc/src/specs/rfc7230_server.ezdoc b/doc/src/specs/rfc7230_server.ezdoc new file mode 100644 index 0000000..d35d877 --- /dev/null +++ b/doc/src/specs/rfc7230_server.ezdoc @@ -0,0 +1,891 @@ +::: RFC7230 HTTP/1.1 server + +This document lists the rules the Cowboy server follows based +on the RFC7230 HTTP specifications. + +:: Listener + +The default port for "http" connections is 80. The connection +uses plain TCP. (RFC7230 2.7.1) + +The default port for "https" connections is 443. The connection +uses TLS. (RFC7230 2.7.2) + +Any other port may be used for either of them. + +:: Before the request + +A configurable number of empty lines (CRLF) preceding the request +must be ignored. At least 1 empty line must be ignored. (RFC7230 3.5) + +When receiving a response instead of a request, identified by the +status-line which starts with the HTTP version, the server must +reject the message with a 501 status code and close the connection. (RFC7230 3.1) + +:: Request + +It is only necessary to parse elements required to process the +request. (RFC7230 2.5) + +Parsed elements are subject to configurable limits. A server must +be able to parse elements at least as long as it generates. (RFC7230 2.5) + +The request must be parsed as a sequence of octets in an encoding +that is a superset of US-ASCII. (RFC7230 2.5) + +``` +HTTP-request = request-line *( header-field CRLF ) CRLF [ message-body ] +``` + +The general format of HTTP requests is strict. No empty line is +allowed in-between components except for the empty line +indicating the end of the list of headers. + +It is not necessary to read the message-body before processing +the request as the message-body may be dropped depending on the +outcome of the processing. + +The time the request (request line and headers) takes to be +received by the server must be limited and subject to configuration. +A server must wait at least 5 seconds before dropping the connection. +A 418 status code must be sent if the request line was received +fully when the timeout is triggered. + +An HTTP/1.1 server must understand any valid HTTP/1.0 request, +and respond to those with an HTTP/1.1 message that only use +features understood or safely ignored by HTTP/1.0 clients. (RFC7230 A) + +:: Request line + +It is recommended to limit the request-line length to a minimum +of 8000 octets. However, as the possible line length is highly +dependent on what form the request-target takes, it is preferrable +to limit each individual components of the request-target. (RFC7230 3.1.1) + +A request line too long must be rejected with a 414 status code +and the closing of the connection. (RFC7230 3.1.1) + +``` +method SP request-target SP version CRLF +``` + +:: Method + +``` +method = token ; case sensitive +token = 1*tchar +tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA +``` + +The request method is defined as 1+ token characters. An invalid +or empty method must be rejected with a 400 status code and the +closing of the connection. (RFC7230 3.1.1, RFC7230 3.2.6) + +In practice the only characters in use by registered methods are +uppercase letters [A-Z] and the dash "-". (IANA HTTP Method Registry) + +The length of the method must be subject to a configurable limit. +A method too long must be rejected with a 501 status code and the +closing of the connection. (RFC7230 3.1.1) + +A good default for the method length limit is the longest method +length the server implements. (RFC7230 3.1.1) + +:: Between method and request-target + +A request that uses anything other than SP as separator between +the method and the request-target must be rejected with a 400 +status code and the closing of the connection. (RFC7230 3.1.1, RFC7230 3.5) + +:: Request target + +There are four request-target forms. A server must be able to +handle at least origin-form and absolute-form. The other two +forms are specific to the CONNECT and site-wide OPTIONS method, +respectively. (RFC7230 5.3.2) + +The fragment part of the target URI is not sent. It must be +ignrored by a server receiving it. (RFC7230 5.1) + +``` +request-target = origin-form / absolute-form / authority-form / asterisk-form +``` + +Any other form is invalid and must be rejected with a 400 +status code and the closing of the connection. + +: origin-form + +origin-form is used when the client does not connect to a proxy, +does not use the CONNECT method and does not issue a site-wide +OPTIONS request. (RFC7230 5.3.1) + +``` +origin-form = absolute-path [ "?" query ] +absolute-path = 1*( "/" segment ) +segment = *pchar +query = *( pchar / "/" / "?" ) + +pchar = unreserved / pct-encoded / sub-delims / ":" / "@" +unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" +pct-encoded = "%" HEXDIG HEXDIG +sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" +``` + +The scheme is either resolved from configuration or is "https" +when on a TLS connection and "http" otherwise. (RFC7230 5.5) + +The authority is sent in the host header. (RFC7230 5.3.1, RFC7230 5.5) + +The absolute-path always starts with "/" and ends with either "?", "#" +or the end of the URI. (RFC3986 3.3) + +The query starts with "?" and ends with "#" or the end of the URI. (RFC3986 3.4) + +The path and query must be subject to a configurable limit. +This limit must be at least as high as what the server generates. +A good default would be 8000 characters. (RFC7230 2.5, RFC7230 3.1.1) + +A request with a too long origin-form must be rejected with +a 414 status code and the closing of the connection. (RFC7230 3.1.1) + +: absolute-form + +absolute-form is used when the client connects to a proxy, though +its usage is also allowed when connecting to the server directly. (RFC7230 5.3.2) + +In practice the scheme will be "http" or "https". + +The "http" and "https" schemes based URI take the following form. (RFC7230 2.7.1, RFC7230 2.7.2) + +``` +http-URI = "http:" "//" authority path-abempty [ "?" query ] [ "#" fragment ] +https-URI = "https:" "//" authority path-abempty [ "?" query ] [ "#" fragment ] +``` + +The target URI excludes the fragment component. (RFC7230 5.1) + +This means that the absolute-form uses a subset of absolute-URI. + +``` +absolute-form = ( "http" / "https" ) "://" authority path-abempty [ "?" query ] +authority = host [ ":" port ] +path-abempty = *( "/" segment ) +query = *( pchar / "/" / "?" ) + +host = IP-literal / IPv4address / reg-name +port = *DIGIT + +IP-literal = "[" ( IPv6address / IPvFuture ) "]" + +IPv6address = 6( h16 ":" ) ls32 + / "::" 5( h16 ":" ) ls32 + / [ h16 ] "::" 4( h16 ":" ) ls32 + / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 + / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 + / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 + / [ *4( h16 ":" ) h16 ] "::" ls32 + / [ *5( h16 ":" ) h16 ] "::" h16 + / [ *6( h16 ":" ) h16 ] "::" + +ls32 = ( h16 ":" h16 ) / IPv4address ; least-significant 32 bits of address +h16 = 1*4HEXDIG ; 16 bits of address represented in hexadecimal + +IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet + +dec-octet = DIGIT / %x31-39 DIGIT / "1" 2DIGIT / "2" %x30-34 DIGIT / "25" %x30-35 + +IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ) + +reg-name = *( unreserved / pct-encoded / sub-delims ) + +segment = *pchar +segment-nz = 1*pchar + +pchar = unreserved / pct-encoded / sub-delims / ":" / "@" +unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" +pct-encoded = "%" HEXDIG HEXDIG +sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" +``` + +The scheme and host are case insensitive and normally provided in lowercase. +All other components are case sensitive. (RFC7230 2.7.3) + +Unknown schemes must be rejected with a 400 status code and the +closing of the connection. Because only a fixed number of schemes +are allowed, it is not necessary to limit its length. + +The scheme provided with the request must be dropped. The effective +scheme is either resolved from configuration or is "https" when on +a TLS connection and "http" otherwise. (RFC7230 5.5) + +An authority component with a userinfo component (and its +"@" delimiter) is invalid. The request must be rejected with +a 400 status code and the closing of the connection. (RFC7230 2.7.1) + +A URI with a missing host identifier is invalid. The request must +be rejected with a 400 status code and the closing of the connection. (RFC7230 2.7.1) + +The maximum length for an IPv4address is 15 characters. No +configurable limit is necessary. + +The maximum length for an IPv6address is 47 characters. No +configurable limit is necessary. + +The maximum length for the reg-name component must be subject +to a configurable limit. A good default is 255 characters. (RFC3986 3.2.2, RFC1034 3.1) + +It is not possible to distinguish between an IPv4address and +a reg-name before reaching the end of the string, therefore +the length limit for IPv4address must be ignored until that +point. + +The maximum length for the port component is 5. No configurable +limit is necessary. + +The authority is sent both in the URI and in the host header. +The authority from the URI must be dropped, and the host header +must be used instead. (RFC7230 5.5) + +The path always starts with "/" and ends with either "?", "#" +or the end of the URI. (RFC3986 3.3) + +An empty path component is equivalent to "/". (RFC7230 2.7.3) + +The query starts with "?" and ends with "#" or the end of the URI. (RFC3986 3.4) + +The path and query must be subject to a configurable limit. +This limit must be at least as high as what the server generates. +A good default would be 8000 characters. (RFC7230 2.5, RFC7230 3.1.1) + +A request with a too long component of absolute-form must be rejected with +a 414 status code and the closing of the connection. (RFC7230 3.1.1) + +: authority-form + +When the method is CONNECT, authority-form must be used. This +form does not apply to any other methods which must reject the +request with a 400 status code and the closing of the connection. (RFC7230 5.3.3) + +``` +authority-form = authority +authority = host [ ":" port ] +host = IP-literal / IPv4address / reg-name +port = *DIGIT + +IP-literal = "[" ( IPv6address / IPvFuture ) "]" + +IPv6address = 6( h16 ":" ) ls32 + / "::" 5( h16 ":" ) ls32 + / [ h16 ] "::" 4( h16 ":" ) ls32 + / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 + / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 + / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 + / [ *4( h16 ":" ) h16 ] "::" ls32 + / [ *5( h16 ":" ) h16 ] "::" h16 + / [ *6( h16 ":" ) h16 ] "::" + +ls32 = ( h16 ":" h16 ) / IPv4address ; least-significant 32 bits of address +h16 = 1*4HEXDIG ; 16 bits of address represented in hexadecimal + +IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet + +dec-octet = DIGIT / %x31-39 DIGIT / "1" 2DIGIT / "2" %x30-34 DIGIT / "25" %x30-35 + +IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ) + +reg-name = *( unreserved / pct-encoded / sub-delims ) + +unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" +pct-encoded = "%" HEXDIG HEXDIG +sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" +``` + +An authority component with a userinfo component (and its +"@" delimiter) is invalid. The request must be rejected with +a 400 status code and the closing of the connection. (RFC7230 2.7.1) + +The maximum length for an IPv4address is 15 characters. No +configurable limit is necessary. + +The maximum length for an IPv6address is 47 characters. No +configurable limit is necessary. + +The maximum length for the reg-name component must be subject +to a configurable limit. A good default is 255 characters. (RFC3986 3.2.2, RFC1034 3.1) + +It is not possible to distinguish between an IPv4address and +a reg-name before reaching the end of the string, therefore +the length limit for IPv4address must be ignored until that +point. + +The maximum length for the port component is 5. No configurable +limit is necessary. + +A request with a too long component of authority-form must be rejected with +a 414 status code and the closing of the connection. (RFC7230 3.1.1) + +The authority is either resolved from configuration or is taken +directly from authority-form. (RFC7230 5.5) + +The path and query are empty when using authority-form. (RFC7230 5.5) + +: asterisk-form + +asterisk-form is used for server-wide OPTIONS requests. +It is invalid with any other methods which must reject the +request with a 400 status code and the closing of the connection. (RFC7230 5.3.4) + +``` +asterisk-form = "*" +``` + +The asterisk-form always has a length of 1. No configurable limit +is necessary. + +The authority is empty when using asterisk-form. + +The path and query are empty when using asterisk-form. (RFC7230 5.5) + +:: Between request-target and version + +A request that uses anything other than SP as separator between +the request-target and the version must be rejected with a 400 +status code and the closing of the connection. (RFC7230 3.1.1, RFC7230 3.5) + +:: Request version + +``` +version = "HTTP/1.0" / "HTTP/1.1" +``` + +Any version number other than HTTP/1.0 or HTTP/1.1 must be +rejected by a server or intermediary with a 505 status code. (RFC7230 2.6, RFC7230 A.2) + +A request that has whitespace different than CRLF following the +version must be rejected with a 400 status code and the closing +of the connection. (RFC7230 3.1.1) + +A request that has any whitespace or characters different than +CRLF following the version must be rejected with a 400 status +code and the closing of the connection. (RFC7230 3.1.1) + +:: Request headers + +``` +headers = *( header-field CRLF ) CRLF +header-field = field-name ":" OWS field-value OWS + +field-name = token +field-value = *( SP / HTAB / %21-7E / %80-FF ) + +OWS = *( SP / HTAB ) +``` + +The header field name is case insensitive. (RFC7230 3.2) + +HTTP/2 requires header field names to be lowercase. It is +perfectly acceptable for a server supporting both to convert +HTTP/1.1 header names to lowercase when they are received. (draft-ietf-httpbis-http2-15 8.1.2.1) + +Messages that contain whitespace before the header name must +be rejected with a 400 status code and the closing of the +connection. (RFC7230 3.2.4) + +Messages that contain whitespace between the header name and +colon must be rejected with a 400 status code and the closing +of the connection. (RFC7230 3.2.4) + +The header name must be subject to a configurable limit. A +good default is 50 characters, well above the longest registered +header. Such a request must be rejected with a 431 status code +and the closing of the connection. (RFC7230 3.2.5, RFC6585 5, IANA Message Headers registry) + +The header value and the optional whitespace around it must be +subject to a configurable limit. There is no recommendations +for the default. 4096 characters is known to work well. Such +a request must be rejected with a 431 status code and the closing +of the connection. (RFC7230 3.2.5, RFC6585 5) + +Optional whitespace before and after the header value is not +part of the value and must be dropped. + +The order of header fields with differing names is not significant. (RFC7230 3.2.2) + +The normal procedure for parsing headers is to read each header +field into a hash table by field name until the empty line. (RFC7230 3) + +Requests with duplicate content-length or host headers must be rejected +with a 400 status code and the closing of the connection. (RFC7230 3.3.2) + +Other duplicate header fields must be combined by inserting a comma +between the values in the order they were received. (RFC7230 3.2.2) + +Duplicate header field names are only allowed when their value is +a comma-separated list. In practice there is no need to perform +a check while reading the headers as the value will become invalid +and the error can be handled while parsing the header later on. (RFC7230 3.2.2) + +The request must not be processed until all headers have arrived. (RFC7230 3.2.2) + +The number of headers allowed in a request must be subject to +a configurable limit. There is no recommendations for the default. +100 headers is known to work well. Such a request must be rejected +with a 431 status code and the closing of the connection. (RFC7230 3.2.5, RFC6585 5) + +When parsing header field values, the server must ignore empty +list elements, and not count those as the count of elements present. (RFC7230 7) + +The information in the via header is largely unreliable. (RFC7230 5.7.1) + +:: Request body + +``` +message-body = *OCTET +``` + +The message body is the octets after decoding any transfer +codings. (RFC7230 3.3) + +A request has a message body only if it includes a transfer-encoding +header or a non-zero content-length header. (RFC7230 3.3) + +``` +Transfer-Encoding = 1#transfer-coding + +transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / transfer-extension +transfer-extension = token *( OWS ";" OWS transfer-parameter ) +transfer-parameter = token BWS "=" BWS ( token / quoted-string ) +``` + +The transfer-coding is case insensitive. (RFC7230 4) + +There are no known other transfer-extension with the exception of +deprecated aliases "x-compress" and "x-gzip". (IANA HTTP Transfer Coding Registry, +RFC7230 4.2.1, RFC7230 4.2.3, RFC7230 8.4.2) + +A server must be able to handle at least chunked transfer-encoding. +This is also the only coding that sees widespread use. (RFC7230 3.3.1, RFC7230 4.1) + +Messages encoded more than once with chunked transfer-encoding +must be rejected with a 400 status code and the closing of the +connection. (RFC7230 3.3.1) + +Messages where chunked, when present, is not the last +transfer-encoding must be rejected with a 400 status code +and the closing of the connection. (RFC7230 3.3.3) + +Some non-conformant implementations send the "deflate" compressed +data without the zlib wrapper. (RFC7230 4.2.2) + +Messages encoded with a transfer-encoding the server does not +understand must be rejected with a 501 status code and the +closing of the connection. (RFC7230 3.3.1) + +A server can reject requests with a body and no content-length +header with a 411 status code. (RFC7230 3.3.3) + +``` +Content-Length = 1*DIGIT +``` + +A request with an invalid content-length header must be rejected +with a 400 status code and the closing of the connection. (RFC7230 3.3.3) + +The content-length header ranges from 0 to infinity. Requests +with a message body too large must be rejected with a 413 status +code and the closing of the connection. (RFC7230 3.3.2) + +When a message includes both transfer-encoding and content-length +headers, the content-length header must be removed before processing +the request. (RFC7230 3.3.3) + +If a socket error occurs while reading the body the server +must send a 400 status code response and close the connection. (RFC7230 3.3.3, RFC7230 3.4) + +If a timeout occurs while reading the body the server must +send a 408 status code response and close the connection. (RFC7230 3.3.3, RFC7230 3.4) + +: Body length + +The length of a message with a transfer-encoding header can +only be determined on decoding completion. (RFC7230 3.3.3) + +The length of a message with a content-length header is +the numeric value in octets found in the header. (RFC7230 3.3.3) + +A message with no transfer-encoding or content-length header +has a body length of 0. (RFC7230 3.3.3) + +: Chunked transfer-encoding + +``` +chunked-body = *chunk last-chunk trailer-part CRLF + +chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF +chunk-size = 1*HEXDIG +chunk-data = 1*OCTET ; a sequence of chunk-size octets + +last-chunk = 1*("0") [ chunk-ext ] CRLF +``` + +The chunk-size field is a string of hex digits indicating the size of +the chunk-data in octets. + +``` +chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) +chunk-ext-name = token +chunk-ext-val = token / quoted-string +``` + +Unknown chunk extensions must be ignored. (RFC7230 4.1.1) + +The chunk-size line length must be subject to configuration. +There are no recommended defaults, although 100 octets should work. +Requests with a too long line must be rejected with a 400 status +code and the closing of the connection. + +``` +trailer-part = *( header-field CRLF ) +``` + +Trailing headers must not include transfer-encoding, content-length, +host, cache-control, expect, max-forwards, pragma, range, te, +if-match, if-none-match, if-modified-since, if-unmodified-since, +if-range, www-authenticate, authorization, proxy-authenticate, +proxy-authorization, age, cache-control, expires, date, location, +retry-after, vary, warning, content-encoding, content-type, +content-range, or trailer. (RFC7230 4.1.2) + +Trailer headers can be ignored safely. (RFC7230 4.1.2) + +When trailer headers are processed, invalid headers must be ignored. +Valid headers must be added to the list of headers of the request. (RFC7230 4.1.2) + +The number of trailer headers must be subject to configuration. +There is no known recommendations for the default. A value of 10 +should cover most cases. Requests with too many trailer headers +must be rejected with a 431 status code and the closing of the +connection. (RFC6585 5) + +Upon completion of chunk decoding the server must add a content-length +header with the value set to the total length of data read. (RFC7230 4.1.3) + +Upon completion of chunk decoding the server must remove "chunked" +from the transfer-encoding header. This header must be removed if +it becomes empty following this removal. (RFC7230 4.1.3) + +Upon completion of chunk decoding the server must remove the trailer +header from the list of headers. (RFC7230 4.1.3) + +``` +Trailer = 1#field-name +``` + +The trailer header can be used to list the headers found in the +trailer. A server must have the option of ignoring trailer headers +that were not listed in the trailer header. (RFC7230 4.4) + +The trailer header must be listed in the connection header field. +Trailers must be ignored otherwise. + +:: Connection management + +Never assume any two requests on a single connection come +from the same user agent. (RFC7230 2.3) + +``` +Connection = 1#token ; case-insensitive +``` + +The connection token is either case insensitive "close", "keep-alive" +or a header field name. + +There are no corresponding "close" or "keep-alive" headers. (RFC7230 8.1, RFC7230 A.2) + +The connection header is valid only for the immediate connection, +alongside any header field it lists. (RFC7230 6.1) + +The server must determine if the connection is persistent for +every message received by looking at the connection header and +HTTP version. (RFC7230 6.3) + +HTTP/1.1 requests with no "close" option and HTTP/1.0 with the +"keep-alive" option indicate the connection will persist. (RFC7230 6.1, RFC7230 6.3) + +HTTP/1.1 requests with the "close" option and HTTP/1.0 with no +"keep-alive" option indicate the connection will be closed +upon reception of the response by the client. (RFC7230 6.1, RFC7230 6.3) + +The maximum number of requests sent using a persistent connection +must be subject to configuration. The connection must be closed +when the limit is reached. (RFC7230 6.3) + +A server that doesn't want to read the entire body of a message +must close the connection, if possible after sending the "close" +connection option in the response. (RFC7230 6.3) + +A server can receive more than one request before any response +is sent. This is called pipelining. The requests can be processed +in parallel if they all have safe methods. Responses must be sent +in the same order as the requests. (RFC7230 6.3.2) + +The server must reject abusive traffic by closing the connection. +Abusive traffic can come from the form of too many requests in a +given amount of time, or too many concurrent connections. Limits +must be subject to configuration. (RFC7230 6.4) + +The server must close inactive connections. The timeout +must be subject to configuration. (RFC7230 6.5) + +The server must monitor connections for the close signal +and close the socket on its end accordingly. (RFC7230 6.5) + +A connection close may occur at any time. (RFC7230 6.5) + +The server must not process any request after sending or +receiving the "close" connection option. (RFC7230 6.6) + +The server must close the connection in stages to avoid the +TCP reset problem. The server starts by closing the write +side of the socket. The server then reads until it detects +the socket has been closed, until it can be certain its +last response has been received by the client, or until +a close or timeout occurs. The server then fully close the +connection. (6.6) + +:: Routing + +``` +Host = authority ; same as authority-form +``` + +An HTTP/1.1 request that lack a host header must be rejected with +a 400 status code and the closing of the connection. (RFC7230 5.4) + +An HTTP/1.0 request that lack a host header is valid. Behavior +for these requests is configuration dependent. (RFC7230 5.5) + +A request with an invalid host header must be rejected with a +400 status code and the closing of the connection. (RFC7230 5.4) + +An authority component with a userinfo component (and its +"@" delimiter) is invalid. The request must be rejected with +a 400 status code and the closing of the connection. (RFC7230 2.7.1) + +When using absolute-form the URI authority component must be +identical to the host header. Invalid requests must be rejected +with a 400 status code and the closing of the connection. (RFC7230 5.4) + +When using authority-form the URI authority component must be +identical to the host header. Invalid requests must be rejected +with a 400 status code and the closing of the connection. + +The host header is empty when the authority component is undefined. (RFC7230 5.4) + +The effective request URI can be rebuilt by concatenating scheme, +"://", authority, path and query components. (RFC7230 5.5) + +Resources with identical URI except for the scheme component +must be treated as different. (RFC7230 2.7.2) + +:: Response + +A server can send more than one response per request only when a +1xx response is sent preceding the final response. (RFC7230 5.6) + +A server that does parallel pipelining must send responses in the +same order as the requests came in. (RFC7230 5.6) + +``` +HTTP-response = status-line *( header-field CRLF ) CRLF [ message-body ] +``` + +The response format must be followed strictly. + +``` +status-line = HTTP-version SP status-code SP reason-phrase CRLF +status-code = 3DIGIT +reason-phrase = *( HTAB / SP / VCHAR / obs-text ) +``` + +A server must send its own version. (RFC7230 2.6) + +An HTTP/1.1 server may send an HTTP/1.0 version for compatibility purposes. (RFC7230 2.6) + +RFC6585 defines additional status code a server can use to reject +messages. (RFC7230 9.3, RFC6585) + +:: Response headers + +In responses, OWS must be generated as SP or not generated +at all. RWS must be generated as SP. BWS must not be +generated. (RFC7230 3.2.3) + +``` +header-field = field-name ":" SP field-value + +field-name = token ; case-insensitive +field-value = *( SP / %21-7E / %80-FF ) +``` + +In quoted-string found in field-value, quoted-pair must only be +used for DQUOTE and backslash. (RFC7230 3.2.6) + +The server must not generate comments in header values. + +HTTP header values must use US-ASCII encoding and must only send +printable characters or SP. (RFC7230 3.2.4, RFC7230 9.4) + +The server must not generate empty list elements in headers. (RFC7230 7) + +When encoding an URI as part of a response, only characters that +are reserved need to be percent-encoded. (RFC7230 2.7.3) + +The set-cookie header must be handled as a special case. There +must be exactly one set-cookie header field per cookie. (RFC7230 3.2.2) + +The server must list headers for or about the immediate connection +in the connection header field. (RFC7230 6.1) + +A server that does not support persistent connections must +send "close" in every non-1xx response. (RFC7230 6.1) + +A server must not send a "close" connection option +in 1xx responses. (RFC7230 6.1) + +The "close" connection must be sent in a message when the +sender knows it will close the connection after fully sending +the response. (RFC7230 6.6) + +A server must close the connection after sending or +receiving a "close" once the response has been sent. (RFC7230 6.6) + +A server must send a "close" in a response to a request +containing a "close". (RFC7230 6.6) + +:: Response body + +Responses to HEAD requests never include a message body. (RFC7230 3.3) + +2xx responses to CONNECT requests never include a message +body. (RFC7230 3.3) + +1xx, 204 and 304 responses never include a message body. (RFC7230 3.3) + +Responses to HEAD requests and 304 responses can include a +content-length or transfer-encoding header. Their value must +be the same as if the request was an unconditional GET. (RFC7230 3.3, RFC7230 3.3.1, RFC7230 3.3.2) + +1xx, 204 responses and 2xx responses to CONNECT requests must +not include a content-length or transfer-encoding header. (RFC7230 3.3.1, RFC7230 3.3.2) + +``` +message-body = *OCTET +``` + +The message body is the octets after decoding any transfer +codings. (RFC7230 3.3) + +When the length is known in advance, the server must send a +content-length header, including if the length is 0. (RFC7230 3.3.2, RFC7230 3.3.3) + +When the length is not known in advance, the chunked transfer-encoding +must be used. (RFC7230 3.3.2, RFC7230 3.3.3) + +For compatibility purposes a server can send no content-length or +transfer-encoding header. In this case the connection must be +closed after the response has been sent fully. (RFC7230 3.3.2, RFC7230 3.3.3) + +The content-length header must not be sent when a transfer-encoding +header already exists. (RFC7230 3.3.2) + +The server must not apply the chunked transfer-encoding more than +once. (RFC7230 3.3.1) + +The server must apply the chunked transfer-encoding last. (RFC7230 3.3.1) + +The transfer-encoding header must not be sent in responses to +HTTP/1.0 requests, or in responses that use the HTTP/1.0 version. +No transfer codings must be applied in these cases. (RFC7230 3.3.1) + +``` +TE = #t-codings + +t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) +t-ranking = OWS ";" OWS "q=" rank +rank = ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] ) +``` + +Trailers can only be sent if the request includes a TE header +containing "trailers". (RFC7230 4.1.2) + +The presence of "chunked" in a TE header must be ignored as it +is always acceptable with HTTP/1.1. (RFC7230 4.3) + +A qvalue of 0 in the TE header means "not acceptable". (RFC7230 4.3) + +The lack of a TE header or an empty TE header means only "chunked" +(with no trailers) or no transfer-encoding is acceptable. (RFC7230 4.3) + +The TE header must be listed in the connection header field, +or must be ignored otherwise. + +Trailer headers must be listed in the trailer header field value. (RFC7230 4.4) + +When defined, the trailer header must also be listed in the connection header. (RFC7230 4.4) + +:: Upgrade + +``` +Upgrade = 1#protocol + +protocol = protocol-name ["/" protocol-version] +protocol-name = token +protocol-version = token +``` + +The upgrade header contains the list of protocols the +client wishes to upgrade to, in order of preference. (RFC7230 6.7) + +The upgrade header can be safely ignored. (RFC7230 6.7) + +The upgrade header must be listed under the connection header, +or must be ignored otherwise. (RFC7230 6.7) + +A server accepting an upgrade request must send a 101 status +code with a upgrade header listing the protocol(s) it upgrades +to, in layer-ascending order. In addition the upgrade header +must be listed in the connection header. (RFC7230 6.7) + +A server must not switch to a protocol not listed in the +request's upgrade header. (RFC7230 6.7) + +A server that sends a 426 status code must include a upgrade +header listing acceptable protocols in order of preference. (RFC7230 6.7) + +A server can send a upgrade header to any response to advertise +its support for other protocols listed in order of preference. (RFC7230 6.7) + +Immediately after a server responds with a 101 status code +it must respond to the original request using the new protocol. (RFC7230 6.7) + +A server must not switch protocols unless the original message's +semantics can be honored by the new protocol. OPTIONS requests +can be honored by any protocol. (RFC7230 6.7) + +A server must ignore an upgrade header received by an HTTP/1.0 +request. (RFC7230 6.7) + +A server receiving both an upgrade header and an expect header +containing "100-continue" must send a 100 response before the +101 response. (RFC7230 6.7) + +The upgrade header field cannot be used for switching the +connection protocol (e.g. TCP) or switching connections. (RFC7230 6.7) + +:: Compatibility + +A server can choose to be non-conformant to the specifications +for the sake of compatibility. Such behavior can be enabled +through configuration and/or software identification. (RFC7230 2.5) |