On Fri, Mar 15, 2013 at 22:01 -0400, PJ Eby wrote: > On Fri, Mar 15, 2013 at 7:16 PM, Carl Meyer <[email protected]> wrote: > > Ok, pending agreement from Holger I'll make a change in the PEP to > > explicitly allow clients to make decisions based on either the rel > > attributes or based on hostnames. Would that be sufficient to address > > your concerns? > > Yes. I just don't want to be in a situation down the road where > there's another argument about this on Catalog-SIG when PyPI starts > using a CDN that, "but it says this in the rel and you're supposed to > use that", and I say, "but Carl and Holger said..." and they go, > "doesn't matter, PEP says" ;-) > > This way, the PEP will be clear that supporting a split of PyPI's > hostnames isn't in current scope.
> > I am also okay with the PEP allowing *.indexhost instead of just > indexhost as the filtering mechanism, as long as it specifies one > *now*. (Again, so this doesn't have to be revisited later.) If > somebody who knows something about CDNs, TUF, etc., needs to weigh in > on it first, that's fine. I just want to know where things stand. One related question. The "rel=internal" links will contain a (md5 currently) hash so if the referenced resource resolves to a file matching that hash, we can be sure about its integrity. What kind of security does host-checking add on top? holger > > Putting the /simple/ API on a CDN isn't quite that easy because it > > currently involves some server-side redirects to effectively make > > project names case-insensitive. > > FWIW, easy_install works fine without this. If a matching index page > isn't found, it checks the full package list. PyPI's redirection just > reduces bandwidth usage and request overhead in the case where the > case of the user's request doesn't match the actual package listing. > But it could be completely static without affecting easy_install and > tools that use its package-finding code. > _______________________________________________ > Catalog-SIG mailing list > [email protected] > http://mail.python.org/mailman/listinfo/catalog-sig > _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
