RFC 2822 should not be recommended for handling HTTP requests

[camper42]

According to RFC 9110, the preferred date/time format for HTTP is defined by RFC 5322, which has replaced RFC 2822.

One notable difference is that the zone field should always use GMT or be omitted (implying GMT), rather than using the format (( "+" / "-" ) 4DIGIT) / obs-zone.

we faced an header issue while using uv, which use jiff processing HTTP header.

[BurntSushi]

This is interesting, because I had thought RFC 2822 specifically defined the date format for use in things like HTTP. But it does seem like RFC 9110 defines something a bit stricter. It is also interesting that most HTTP servers seem to happily accept RFC 2822, and indeed, the stricter format prescribed by RFC 9110 is compatible with RFC 2822 from what I can tell. So if HTTP servers use an RFC 2822 parser, then they would read Jiff's output fine. But an HTTP server that exclusively supports the latest updates to RFC 9110 would not.

Either way, I think MDN is probably right here. I'll add a new method for printing timestamps in a way that is explicitly compatible with RFC 9110. One additional thing, besides using GMT instead of -0000, is that two digits for the day are always used. (This makes it a fixed length value.)

Now I'm left wondering what relationship RFC 2822 has to HTTP.

[BurntSushi]

And perhaps even more confusingly, RFC 2822 considers the use of GMT (instead of -0000, which mean the same thing) to be obsolete: https://datatracker.ietf.org/doc/html/rfc2822#section-3.3

[camper42]

RFC 5322 (Internet Message Format):

• Document type: RFC - Draft Standard
• Updated by RFC 6854
• Obsoletes RFC 2822

From RFC 5322 Abstract:

This document specifies the Internet Message Format (IMF), a syntax
for text messages that are sent between computer users, within the
framework of "electronic mail" messages. This specification is a
revision of Request For Comments (RFC) 2822, which itself superseded
Request For Comments (RFC) 822, "Standard for the Format of ARPA
Internet Text Messages", updating it to reflect current practice and
incorporating incremental changes that were specified in other RFCs.

---

RFC 6854 (Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields):

• Document type: RFC - Proposed Standard

---

RFC 2822 (Internet Message Format)

• Document type: RFC - Proposed Standard
• Obsoleted by RFC 5322
• Updated by RFC 5336, RFC 5335

---

RFC 9110 (HTTP Semantics)

• Document type: RFC - Internet Standard

---

RFC 6854 seems unrelated to date/time format, RFC 5322 is a Draft Standard but preferred by
RFC 9110 (a Internet Standard).

according to About RFCs Statuses, RFC 9110 has higher priority, and even if RFC 5322 is a Draft Standard(An intermediate stage that is no longer used for new standards), it should be prefererd over RFC2822.

[BurntSushi]

Yeah RFC 5322 and RFC 2822 define the same datetime format, so that part is fine. It's the interplay between RFC 9110 and RFC 5322 that is pretty confusing to me. I missed this before, but RFC 9110 does say this:

The preferred format is a fixed-length and single-zone subset of the date and time specification used by the Internet Message Format [RFC5322].

But note that RFC 9110 also says this:

Recipients of timestamp values are encouraged to be robust in parsing timestamps unless otherwise restricted by the field definition. For example, messages are occasionally forwarded over HTTP from a non-HTTP source that might generate any of the date and time specifications defined by the Internet Message Format.

Which could arguably interpreted as a suggestion that HTTP servers should just support parsing RFC 5322 in its entirety. Which is probably why -0000 worked as well as it does: most HTTP servers seem to be pretty flexible in that they accept all of RFC 5322. I don't know why Tencent COS doesn't do this.

Still weird that RFC 5322 considers GMT itself obsolete. ¯\_(ツ)_/¯

[camper42]

it's very confusing indeed...But if we accept that 9110 has the highest priority.

A recipient that parses a timestamp value in an HTTP field MUST accept all three HTTP-date formats.

So, tencent cos server not accepting that outdated format is also a bug.

When a sender generates a field that contains one or more timestamps defined as HTTP-date, the sender MUST generate those timestamps in the IMF-fixdate .

So jiff should support parsing in all three formats, but it is only recommended that the sender use the IMF-fixdate format