Phillip, Thanks for your response.
-----Original Message----- From: Phillip J. Eby [mailto:pje@telecommunity.com] Sent: Thursday, 18 December, 2008 21:59
... And it's not reasonable to expect it to grow special cases for every site that wants to hide the filename in the query string attached to a CGI script.
I absolutely agree it's not reasonable to grow special cases... but the RFCs do provide a standard for describing the content disposition. Perhaps it would be worthwhile to handle that general case. Specifically, one could request the headers for a given URL to determine if a content-disposition filename is supplied. I've put together some sample code which is short, robust, and clean (I hope). This code demonstrates how one might go about querying the content-disposition. See it at: http://paste.turbogears.org/paste/19813 With that code, the filename_test code could go something like this: filename = get_content_disposition_filename(url) or get_filename_the_old_way(url) test_valid_egg_distro(filename) ... or alternatively, one could only perform the content-disposition retrieval when the filename _appears_ to be invalid.
If someone needs to have their files processed by a script, they could always make the path something like:
downman.py/pythonutils-0.2.3.zip
Using either PATH_INFO or mod_rewrite or something similar, at which point easy_install can tell it's looking at a source zipfile, rather than a .py script.
While I agree it's unreasonable for setuptools to have to grow to handle nonstandard cases, I would say the same argument applies to the content providers. They shouldn't have to alter their deployment architecture to accommodate limitations in setuptools, particularly when they're following the web standards. The above solution handles the general case where files can be served through many different content management systems and not just as static file references in the URL. This allows for special urls like http://www.mycompany.com/myproject/latest_distro.jsp, which might generate the content dynamically. Note that the voidspace author is not attempting to "hide" the filename in the get parameters. He's probably using a sort of content management system. Would you consider a patch that incorporates this more robust behavior? Regards, Jason