On Thu, Aug 11, 2011 at 10:47:24AM -0400, Dave Reisner wrote:
On Thu, Aug 11, 2011 at 03:46:51PM +0200, Lukas Fleischer wrote:
On Thu, Aug 11, 2011 at 08:11:25AM -0500, Dan McGee wrote:
On Thu, Aug 11, 2011 at 7:46 AM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> --- * Rules rewritten using a single regular expression. * Added an equivalent lighttpd rewrite rule.
UPGRADING | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/UPGRADING b/UPGRADING index 331870e..aff780f 100644 --- a/UPGRADING +++ b/UPGRADING @@ -22,6 +22,23 @@ ALTER TABLE PackageDepends ADD INDEX (DepName); 6. Run the upload directory transform script ("scripts/uploadbuckets.sh") and rotate the converted directory structure into place.
+7. In order to to provide backward compatible package URLs, enable mod_rewrite +and add the following to your Apache configuration (inside the "VirtualHost" +container or optionally create a ".htaccess" file in the upload directory): + +---- +RewriteEngine on +RewriteRule ^/packages/([^/]{1,2})([^/]*/(PKGBUILD|.*\.tar\.gz))$ /packages/$1/$1$2 +---- + +The following equivalent rule can be used for lighttpd setups: + +---- +url.rewrite-once = ( "^/packages/([^/]{1,2})([^/]*/(PKGBUILD|.*\.tar\.gz))$" => "/packages/$1/$1$2" ) +----
I'm still -1 on this. I don't think we need to assume the contents of these directories in a rewrite rule, nor do I think it makes the rules any clearer. Can we please just use rules that don't make assumptions?
We need to make assumptions here. If we don't, there's no way to determine whether a client tries to fetch the file "foo" from the upload directory of package "fo" or the package upload directory of "foo" when requesting "/packages/fo/foo". Of course, we could check for existence of both files in that case and just use "/packages/fo/foo" if both of them exist, but this is even more unpredictable and difficult to implement. Keep in mind that this is a backward compatibility measure only.
Does this even let me go to http://aur.archlinux.org/packages/gephi/ correctly? I don't think it does.
No. I don't think that we do officially support directory listing, thought. And as I pointed out before, this is impossible to implement.
So, this still seems crazy to me. The solution I proposed works and uses a singular regex which conforms to lighty specifications as far as I can tell. We gain backwards compat, and nothing at all breaks.
Referencing lighty's doc...
http://redmine.lighttpd.net/wiki/1/FrequentlyAskedQuestions
This makes reference to:
http://www.regular-expressions.info/brackets.html
Which clearly shows a backref being used in the match space. The fact that I used an _equivalent_ pattern in sed was for purely for testing purposes to prove that the pattern does what I want it to. Do you know for sure that implementing this rule as I proposed it in lighty syntax does not work?
That doesn't fix the aforementioned issue. Again, this _cannot_ be implemented properly due to the nature of our new directory structure. To give an example, your regular expression will fail to rewrite "/packages/st/st.tar.gz" properly (which even exists in AUR and is not purely hypothetical at all) as it will assume that the URL is already rewritten. If you still don't believe me, please read my last reply in this thread again carefully. Also, I'd like to have equivalent behaviour for Apache and Perl rewrites. Either this, or we only provide one of them.