On Fri, May 10, 2013 at 02:34:34PM +0000, Xyne wrote:
Hi,
pacman/libalpm currently only supports "bare" server URIs of the form
<scheme name> : <hierarchical part>
whereas a full URI is
<scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]
Support for query strings would allow for more flexible server configurations using dynamic content. For the sake of a concrete example, I'm in the middle of rewriting Pacserve and I could really use "?repo=$repo&arch=$arch" to keep all packages in one apparent server directory while still being able to correctly redirect to external mirrors. Redirection requires both values to determine and interpolate the server URL before returning it to Pacman with a 307.
At first I thought this would be relatively easy to do. I took a quick look at the code but I didn't find a common function to affix the file name to the URL (although I did see "sanitize_url" in db.c).
I see two ways of doing this:
1) Support a "$file" variable in the URL. If the URL doesn't contain the variable, add the file name to the end as usual.
2) Remove the query and fragment, treat the URL as usual, then restore the query and fragment.
The first would allow for file names in query strings (e.g. "?file=$file"). It could be used for a build server, for example. Of course, you can extract the file name from the request path but that requires hacking the server code or using something like mod_rewrite to mangle URLS. Having the file name sent in a get variable is much more convenient for server-side programming.
Maybe I didn't understand your problem. But wouldn't using the Content-Disposition header solve it?
In either case, it should be enough to have a single, central function that accepts the template URL and the filename (pkg or db) and returns the full URL. The sanitize_url function would also need to handle query strings and fragments.
Would there be any objection to this if a patch were submitted?