HTTP header fields, which include General-Header (Section 4.3) general-header (section 4.5), Request-Header (Section 5.2) request-header (section 5.3), Response-Header (Section 6.2) response-header (section 6.2), and Entity-Header (Section 7.1) entity-header (section 7.1) fields, follow the same generic format as
that given in Section 3.1 of RFC 822 [7] [9] . Each header field consists
of a name followed immediately by a colon (":"), a single space (SP) character, and the field value.
Field names are case-insensitive. The field value may MAY be preceded by any amount of LWS, though a single SP is preferred.
Header fields can be extended over multiple lines by preceding each extra line with at least one SP or HT, though this is not recommended. Applications SHOULD ought to follow "common form", where one is known or indicated, when generating HTTP constructs, since there might exist some implementations that fail to accept anything beyond the common forms.
field-content = <the OCTETs making up the field-value and consisting of either *TEXT or combinations of token, tspecials {2616} separators, and quoted-string OCTET 並びが field-value を形成し、 *TEXT または token, tspecialsCODE(ABNF)separators, quoted-string の組合せのいずれかにより構成する>
{2616} The field-content does not include any leading or trailing LWS:
linear white space occurring before the first non-whitespace
character of the field-value or after the last non-whitespace
character of the field-value. Such leading or trailing LWS MAY be
removed without changing the semantics of the field value. Any LWS
that occurs between field-content MAY be replaced with a single SP
before interpreting the field value or forwarding the message downstream.
The order in which header fields with differing field names are received is not significant.
However, it is "good practice" to send General-Header general-header fields first,
followed by Request-Header request-header or Response-Header response-header fields, and ending with prior to the Entity-Header entity-header fields.
Multiple HTTP-header message-header
fields with the same field-name {1945,2068} may {2616} MAY be present
in a message if and only if the entire field-value for that header
field is defined as a comma-separated list [i.e., #(values)].
It must MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.
[10] Rework all things request headers · 35b2c8b · whatwg/fetch
( ( 版))
https://github.com/whatwg/fetch/commit/35b2c8b42797e1b2bc8e97f204aaf7c618599202
[11] Align with new Fetch header terminology and unsafe request flag · 6766628 · whatwg/xhr
( ( 版))
https://github.com/whatwg/xhr/commit/676662852dbb08836f3697f293484a78167938bf
[441] Illustrate how headers are (soon to be) divided in the platform · a6b39f5 · whatwg/fetch
( ( 版))
https://github.com/whatwg/fetch/commit/a6b39f5bbc8163f5336c4c384d62480c5003bd5e
[442] Clarify header ideas a bit. Still not great. https://github.com/slightly... · 137ff3d · whatwg/fetch
( ( 版))
https://github.com/whatwg/fetch/commit/137ff3df74d0bb5cbc4aadbbdceb9169d30c3f36
[72] HTML Standard
( 版)
https://html.spec.whatwg.org/#concept-http-equivalent-headers
The HTTP headers are equivalent to fields in other protocols that have the same basic meaning. For example, the HTTP authentication headers are equivalent to the authentication aspects of the FTP protocol.
[102] nextthing.org » Fun With HTTP Headers
( 版)
http://www.nextthing.org/archives/2005/08/07/fun-with-http-headers
[103] HTTP header representation in Fetch
(Anne van Kesteren 著, 版)
https://lists.w3.org/Archives/Public/www-archive/2016Jan/0006.html
[108] Define get(All)ResponseHeader(s) in terms of Fetch
( (annevk著, ))
https://github.com/whatwg/xhr/commit/ecce3904ace0dbe382a652ea1d8e29c7885fe8c4
[111] Web Annotation Data Model
()
https://w3c.github.io/web-annotation/model/wd2/#h-request-header-state
The HTTP request headers to send as a single, complete string.
[112] Web Annotation Data Model
()
https://w3c.github.io/web-annotation/model/wd2/#h-request-header-state
"state": {
"type": "HttpRequestState",
"value": "Accept: application/pdf"
}
[114] Web Annotation Vocabulary
()
https://w3c.github.io/web-annotation/vocab/wd/#h-httprequeststate
[115] Selectors and States
()
https://w3c.github.io/web-annotation/selector-note/#h-httprequeststate_def
[116] Sort and lowercase header names in getAllResponseHeaders() example
(annevk著, )
https://github.com/whatwg/xhr/commit/76b482b68ed9c27e0cc65fd3a6e663999cfc25e4
[117] Editorial: make Request/Response's headers its own concept
(jakearchibald著, )
https://github.com/whatwg/fetch/commit/07999e9e5911ca246de2f31aace16f8eca9003bd
[118] Editorial: Making headers their own property by jakearchibald · Pull Request #575 · whatwg/fetch
()
https://github.com/whatwg/fetch/pull/575
[119] 655389 - CRLF Injection and the parsing of HTTP headers
()
https://bugzilla.mozilla.org/show_bug.cgi?id=655389
[120] draft-nottingham-structured-headers-00 - Structured Headers for HTTP
()
https://tools.ietf.org/html/draft-nottingham-structured-headers-00