RE: HTTP Deprecation Call for Authors

Got it,


If the powers that be decided the GMT format was not the path forward for
whatever reason; be it performance, parse-ability, etc.

Then I believe we have to amend this doc to use the format designated by the
peer WG to stay in line with those standards and be compliant.




From: Darrel Miller <> 
Sent: Thursday, August 10, 2023 7:43 AM
To: Kyzer Davis (kydavis) <>;; Evert Pot
Subject: Re: HTTP Deprecation Call for Authors




The main thread on the issue of using Structured Fields is here


> Not particularly parsable by a human at-a-glance but some implementation
could smear 

> that into a readable date for human consumption easily enough with some
application logic.


That captures the essence of the concerns about moving to Structured Fields.


> Is the date structured field format looks prone to the Year 2038 problem?
I checked a few places but didn't see that brought up.


I was concerned about that when I first read the document. However, the
document says,


>Dates  have a data model that is similar to Integers


In the document, "Integers" are defined as supporting 15 digits.  My
understanding is that 15 digits is more than enough to avoid the 2038 issue.


> Many headers exists that embed a date and most HTTP applications will
already be able to easily parse the GMT format.


You can see from the Retrofit draft that the goal is for HTTP to provide
alternative headers that move away from the HTTP-Date format that has been
used in the past.



You can imagine how big a deal it is to change such widely used fields, and
why there is strong motivation to not introduce new headers that perpetuate
the old format.





Received on Thursday, 10 August 2023 17:36:11 UTC