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.
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
> > 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);
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
Hi
On Tue, 4 Feb 2025 13:40:50 +0100
John Hallam <sw@j.hallam.dk> wrote:
> 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.
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!
On Tue, Feb 04, 2025 at 04:37:18PM +0200, Timo Teras wrote:
> On Tue, 4 Feb 2025 13:40:50 +0100> John Hallam <sw@j.hallam.dk> wrote:> > > 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.> > 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.
Thanks!
> Thank you!
You're very welcome,
John