Tom Samplonius wrote on 02/12/2014 05:01:
Wow, I had no idea that existed; what an incredibly ugly
implementation. Even the name is weird (why "header" singular when it
contains an array of headers?)
Actually, no. HTTP responses contain a single header at the
protocol level, but contain multiple lines. At some point, people
started to each line a “header”, which is actually more strange. I
think that usage may have originated in PHP, actually. At this point,
common usage supports both “header” and “headers”, though “header” is
the more general term. For comparison, no one refers to the separate
fields of a TCP header, as “headers”.
I'm not sure the standards back you up on that, actually: RFC 2616 (the
old HTTP/1.1 spec obsoleted earlier this year) says:
> Request (section 5) and Response (section 6) messages use the generic
message format of RFC 822 [9] for transferring entities
> (the payload of the message). Both types of message consist of a
start-line, zero or more header fields (also known as "headers"),
> an empty line (i.e., a line with nothing preceding the CRLF)
indicating the end of the header fields, and possibly a message-body.
Searching for "header" in RFC 822 (dated 1982!), the first mention is this:
> The syntax of several fields of the rigidly-formated
> ("headers") section is defined in this specification; some of
> these fields must be included in all messages.
So it looks to me like "HTTP header" has always been a synonym for "HTTP
header field" basically forever.
The new RFC 7230 uses slightly different wording and references, but
still takes "header" to mean "header field", not the whole section:
> All HTTP/1.1 messages consist of a start-line followed by a sequence
> of octets in a format similar to the Internet Message Format
> [RFC5322]: zero or more header fields (collectively referred to as
> the "headers" or the "header section"), an empty line indicating the
> end of the header section, and an optional message body.
--
Rowan Collins
[IMSoP]
