[pacman-dev] [RFC] support for URL query strings and fragments

[Mohammad_Alsaleh]

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