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? > >
