Received: from gtux.hallam.dk (gtux.hallam.dk [185.113.128.35])
	by gbr-app-1.alpinelinux.org (Postfix) with ESMTPS id EE46F225BBF
	for <~alpine/apk-tools@lists.alpinelinux.org>; Tue,  4 Feb 2025 12:40:51 +0000 (UTC)
Received: (qmail 10131 invoked from network); 4 Feb 2025 12:40:51 -0000
Received: from umbriel.sconet (umbriel.sconet [192.168.0.31])
  by raphael.sconet ([192.168.0.12])
  with SMTP via TCP; 04 Feb 2025 12:40:51 -0000
Received: (nullmailer pid 5974 invoked by uid 1010);
	Tue, 04 Feb 2025 12:40:50 -0000
Date: Tue, 4 Feb 2025 13:40:50 +0100
From: John Hallam <sw@j.hallam.dk>
To: Timo Teras <timo.teras@iki.fi>
Cc: ~alpine/apk-tools@lists.alpinelinux.org
Subject: Re: [PATCH] libfetch: allow tolerant date parsing
Message-ID: <Z6IK0kIV8iqOlj3k@umbriel.sconet>
References: <Z6H7YCJsDGaH33NF@umbriel.sconet>
 <20250204143043.1f37d794@onyx.my.domain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250204143043.1f37d794@onyx.my.domain>

Hi Timo,

On Tue, Feb 04, 2025 at 02:30:43PM +0200, Timo Teras wrote:

> On Tue, 4 Feb 2025 12:34:56 +0100
> John Hallam <sw@j.hallam.dk> wrote:
> 
> > apk's libfetch is strict when interpreting timestamps in
> > e.g. Last-Modified headers;  other tools and web servers (e.g.
> > Debian's apt-cacher-ng) are lax in generation.
> 
> I was about to ask why not change apt-cacher-ng instead if they are
> broken...
> 
> > The patch below fixes interaction with apt-cacher-ng and allows easy
> > adding of other obsolete timestamp patterns.
> 
> ... but went on to read the spec and it says at
> https://datatracker.ietf.org/doc/html/rfc2616#section-3.3.1
> 
>    HTTP/1.1 clients and servers that parse the date value MUST accept
>    all three formats (for compatibility with HTTP/1.0), though they MUST
>    only generate the RFC 1123 format for representing HTTP-date values
>    in header fields.

  Yup, I was thinking of the "be strict in what you emit and tolerant in
what you accept" saying (was that Jon Postel's?).

> So I hope tyou file an issue against apt-cacher-ng to fix their thing.

  I shall indeed file a Debian bug for apt-cacher-ng.  They do accept
all 3 formats, though generate the wrong one.

> But sounds like libfetch needs fixing too. If going here, it would be
> good to support all three formats. And have the commit message reflect
> that these are obsolete formats but required to be support for
> standards compliance.
> 
> Would you like to update the patch accordingly, or prefer me to do the
> additional changes?

  I'm happy for you to add the extra line for the third format and
provide a suitable commit message for the project.  It may also make
sense to change the comment I moved to above the list of formats to
reflect the reason of standards compliance.

Best wishes

     John