On Tue, 14 Apr 2020 at 11:13, Matthias Bläsing <mblaes...@doppel-helix.eu> wrote: > Yes - it is the _catalog_ not every nbm. Yes this still needs work (for > example instead of loading the catalog and working on the DOM, a > streaming parser should be able to do the modification on-the-fly). The > alternative would be to generate update.xmls for every mirror.
But the catalog is the thing that's polled continuously, whereas nbms are rarely touched. The additional overhead should at least be checked for, although maybe not much different to the plugin centre? > Sorry - no idea what this means. Do you mean, that closer.lua will > reject request because a request limit is reached? Actually it's the redirect into the VM that gets rejected after like ~50 nbms, although potential for closer.lua to reject too i think. Anything that could get the IDE and Ant scripts to download nbms directly from one mirror rather than continuously via all redirects would be an improvement when multiple nbms are being downloaded in one batch. I did a test uninstalling and reinstalling an entire cluster a while back and that also failed, although might not in all cases. > > It might be good if the IDE code followed redirects only for the > > updates.xml, and treated relative links as relative to the catalog > > endpoint anyway? > > This is already the case - the urls are resolved relative to the update > center URL. BUT that URL must not be redirected to mirrors, as it is > our trust anchor. As above, the resolution is a problem - but yes, I made a mistake in what I said, and it's not like I fixed the .htaccess in the first place :-) - we were serving the catalog from the mirrors prior to 11.1. Somehow, we could do with a situation where a mirror is looked up once, and all nbms are downloaded directly from it. But now of course keeping the catalog as the trust anchor too. Maybe your approach is then the right one left. > No, we must _never_ redirect the IDE to fetch the updates.xml from an > untrusted source and the mirror network must be considered untrusted. Well, I meant end users doing that, not us - but good point, it's not really the thing to recommend. That leaves pointing people to try using https://dist.apache.org/repos/dist/release/netbeans/netbeans/11.3/nbms/updates.xml.gz if stuck, which might get frowned upon. :-\ And of course, if we push updated nbms they are manually added into the catalog on the VM at the moment - so the above won't get updates either. Best wishes, Neil --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
