Depending on the ordering of data within a .zip archive is fragile. @EpicWink’s suggestion of an explicit API to request just the metadata makes more sense. That leaves PyPI as the single canonical source of truth parsing the binary blob (a zip today) to determine what the metadata to be served is.
There are potential dangers to a range request trying to get lucky with a partial zip file read. You now need to worry about the zip file format internals itself including if someone crafts a malicious zip file that appears to have the metadata desired in the range-requested end but actually yields different metadata when parsed as a whole file.
I know too much about the zip archive format and zipfile implementations to understand that while this type of attack feels unlikely… I can’t rule it out. The code paths involved everywhere are complex and not something I recommend depending on. Doing this is relying upon an implementation of file format parsing outside of our direct control to be lucky enough to have a convenient side effect.
Yes, zip files are supposed to have an end of file central directory. But despite that, they also have inline file headers which can be used, various things do not guarantee that this redundant duplicate information actually matches up making it possible to see two different views of the contents.
If it were an archive format of our own design and entirely under our control I would feel less nervous about this concept. It isn’t.