HTTP/2 404

[guillermosantana]

Loading composer repositories with package information In CurlDownloader.php line 623:

The "https://wpackagist.org/p/providers-2023-06%248a65709b12e9c0905f9c0678a
5f68dd40aefda8cf3215d033361075ea03c1a0a.json" file could not be downloaded
(HTTP/2 404 )

[cjezowicz]

I'm just now getting this same issue. @guillermosantana did you find a resolution?

Edit: Sorry it's a nearly identical issue due to what I assume is a cached or versioned file that is returning the 404

In CurlDownloader.php line 623:
The "https://wpackagist.org/p/providers-2023-06%2435a06a75072fc19fabd5ce8e4c131f69c3d22f617aa646a72d8d28e4f32eae57.json" file could not be downloaded (HTTP/2 404 ) 

2nd Edit: It resolved itself after a few more attempts but should be looked into with a lower priority to prevent confusion for new users.

[mcaskill]

I've stumbled upon this today. The issue lasted for about 1 minute.

In CurlDownloader.php line 623:
The "https://wpackagist.org/p/providers-2023-03%247ab80b924717a73630f706217bb9022cc74fda9143a13d724643fc9eac350292.json" file could not be downloaded (HTTP/2 404)

[cjezowicz]

@mcaskill I read somewhere else that it may be a local issue related to composer caching. I do not believe it's an issue with wppackagist specifically but could be wrong.

[NoelLH]

Sorry for not replying before. There are definitely some considerations in terms of how Wpackagist serves up its metadata which have some bearing here, and we have been tweaking it.

We moved the live setup behind a CDN on 25 May. This was done:

• partly in the hope of mitigating 404 edge cases as @guillermosantana saw (by letting "old" files accessed on the root index of metadata) live a little longer, provided they were accessed recently and are in the cache;
• to speed up responses in most cases; and
• because running costs are getting high and we needed to do something to keep the service online & free. (We're also looking at adding GitHub sponsorship options.)

In retrospect, this probably made the problem better and/or worse depending on your timing and use case. I hit 404s downstream myself in early/mid-June, and realised that including the root metadata file in potentially long-ish caches is a problem, because there is then a decent chance of Composer getting a copy which tells it to look for versioned files that are too old to be in cache.

On 15 June, I set a lower limit on the cache lifetime for the root index (https://wpackagist.org/packages.json). But I can see at least some of you still had trouble after that.

It's quite hard to assess the impact on real people because the % of 404s in absolute terms remains low and old URLs could always be bot-indexed. We also seem to see a quite significant impact on costs from small changes in the root file's cache times, so unfortunately we might have to compromise a little with this.

There's another infrastructure change that is blocking it tonight, but I hope to reduce the root cache lifetime by a further order of magnitude tomorrow. I'd be keen to hear how everyone finds the service in the subsequent couple of weeks.