Subject: [PATCH] libfetch: allow tolerant date parsing

From: John Hallam <[email-masked]>
Date: Tue, 4 Feb 2025 12:34:56 +0100

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.

The patch below fixes interaction with apt-cacher-ng and allows easy
adding of other obsolete timestamp patterns.

Built and tested with apk-tools 2.14.9.

Best wishes

     John Hallam

--- a/libfetch/http.c
+++ b/libfetch/http.c
@@ -479,11 +479,21 @@
 {
 	char *locale, *r;
 	struct tm tm;
+        int i;
+	/* XXX should add support for date-2 and date-3 */
+	const char *fmts[] ={ "%a, %d %b %Y %H:%M:%S GMT",
+			      "%a %b %d %H:%M:%S %Y",
+			      NULL,	
+	};
 
 	locale = strdupa(setlocale(LC_TIME, NULL));
 	setlocale(LC_TIME, "C");
-	r = strptime(p, "%a, %d %b %Y %H:%M:%S GMT", &tm);
-	/* XXX should add support for date-2 and date-3 */
+	i=0;
+	while(fmts[i] != NULL) {
+		r = strptime(p, fmts[i], &tm);
+		if(r != NULL) break;
+		i++;
+	}
 	setlocale(LC_TIME, locale);
 	if (r == NULL)
 		return (-1);

---

From: Timo Teras <[email-masked]>
Date: Tue, 4 Feb 2025 14:30:43 +0200

On Tue, 4 Feb 2025 12:34:56 +0100
John Hallam <[email-masked]> wrote:

> 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...

> 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.

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

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?

Timo

---

From: John Hallam <[email-masked]>
Date: Tue, 4 Feb 2025 13:40:50 +0100

Hi Timo,

>    only generate the RFC 1123 format for representing HTTP-date values

  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.

> Would you like to update the patch accordingly, or prefer me to do the

  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

---

From: Timo Teras <[email-masked]>
Date: Tue, 4 Feb 2025 16:37:18 +0200

Hi

On Tue, 4 Feb 2025 13:40:50 +0100

> reflect the reason of standards compliance.

I ended up just unrolling the loop as it is more readable for me that
way, and I don't see more formats coming up.

Pushed as:
https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/908efa92701c64e08936c681688529415b2258d1

and cherry picked to 2.14-stable.

Thank you!

---

From: John Hallam <[email-masked]>
Date: Tue, 4 Feb 2025 17:19:47 +0100

> and cherry picked to 2.14-stable.

  Thanks!

> Thank you!

  You're very welcome,

         John