| View previous topic :: View next topic |
| Author |
Message |
loloyd
-
Joined: 03 Mar 2006
Posts: 435
Location: Philippines
|
 Posted: Wed Apr 02, 2014 8:36 am Post subject: Possible var bugs on URL Rewriting, Abyss version 2.9.0.1 |
 |
|
Hello Aprelium,
Long time no see. Anyway, I noticed something possibly amiss with the 2.9.0.1 version of Abyss. My URL Rewrites used to work in previous versions of Abyss and these things are pretty straightforward, as much as I can understand them.
These are my key .htaccess constraints.
| Code: | RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^ index.php [L] |
I then made up my Abyss URL Rewrite rules and these are what I got from the debugging logs. Next, I browsed for https://192.168.10.60/sandbox/cenmap/?q=welcome_census_mapping_submission_facility - which is a Drupal-based project of mine.
Note that these logs have been redacted for hopefully easier reading :-).
| Code: | Request URI=[/sandbox/cenmap/]:
SERVER_SOFTWARE=Abyss/2.9.0.1-X1-Win32 AbyssLib/2.9.0.0
REQUEST_URI=/sandbox/cenmap/?q=welcome_census_mapping_submission_facility
URL=/sandbox/cenmap/?q=welcome_census_mapping_submission_facility
SCRIPT_URL=/sandbox/cenmap/?q=welcome_census_mapping_submission_facility
SCRIPT_NAME=/sandbox/cenmap/
SCRIPT_FILENAME=sandbox/cenmap/
REQUEST_FILENAME=sandbox/cenmap/
QUERY_STRING=q=welcome_census_mapping_submission_facility
CONTENT_LENGTH=0
Rule #1: Regex [^\/sandbox\/cenmap\/(.*)$] matches with the request URI
Testing the conditions:
REQUEST_FILENAME (value: [C:\Websites\default_https/sandbox/cenmap/]) expanded from [sandbox/cenmap/]) is not an empty fileFALSE
The conditions are not verified (FALSE).
Rule #2: Regex [^\/sandbox\/cenmap\/(.*)$] matches with the request URI
Testing the conditions:
REQUEST_FILENAME (value: [C:\Websites\default_https/sandbox/cenmap/]) expanded from [sandbox/cenmap/]) is not a fileTRUE
REQUEST_FILENAME (value: [C:\Websites\default_https/sandbox/cenmap/]) expanded from [sandbox/cenmap/]) is not a directoryTRUE
REQUEST_FILENAME (value: [C:\Websites\default_https/sandbox/cenmap/]) expanded from [sandbox/cenmap/]) is an empty fileTRUE
REQUEST_URI (value: [C:\Websites\default_https//sandbox/cenmap/?q=welcome_census_mapping_submission_facility]) expanded from [/sandbox/cenmap/?q=welcome_census_mapping_submission_facility]) is not a fileTRUE
REQUEST_URI (value: [C:\Websites\default_https//sandbox/cenmap/?q=welcome_census_mapping_submission_facility]) expanded from [/sandbox/cenmap/?q=welcome_census_mapping_submission_facility]) is not a directoryTRUE
REQUEST_URI (value: [C:\Websites\default_https//sandbox/cenmap/?q=welcome_census_mapping_submission_facility]) expanded from [/sandbox/cenmap/?q=welcome_census_mapping_submission_facility]) is an empty fileTRUE
QUERY_STRING (value: [q=welcome_census_mapping_submission_facility]) does not match with [^q=.*] => FALSE
Matching results:
%0=q=welcome_census_mapping_submission_facility
Last condition is FALSE. Validation of next conditions is useless.
===> No rule matches.
----------------------------------------------
Request URI=[/sandbox/cenmap/misc/jquery.js]:
REQUEST_URI=/sandbox/cenmap/misc/jquery.js?v=1.4.4
URL=/sandbox/cenmap/misc/jquery.js?v=1.4.4
SCRIPT_URL=/sandbox/cenmap/misc/jquery.js?v=1.4.4
SCRIPT_NAME=/sandbox/cenmap/misc/jquery.js
SCRIPT_FILENAME=sandbox/cenmap/misc/jquery.js
REQUEST_FILENAME=sandbox/cenmap/misc/jquery.js
QUERY_STRING=v=1.4.4
CONTENT_LENGTH=0
Rule #1: Regex [^\/sandbox\/cenmap\/(.*)$] matches with the request URI
Testing the conditions:
REQUEST_FILENAME (value: [C:\Websites\default_https/sandbox/cenmap/misc/jquery.js]) expanded from [sandbox/cenmap/misc/jquery.js]) is not an empty fileFALSE
The conditions are not verified (FALSE).
Rule #2: Regex [^\/sandbox\/cenmap\/(.*)$] matches with the request URI
Testing the conditions:
REQUEST_FILENAME (value: [C:\Websites\default_https/sandbox/cenmap/misc/jquery.js]) expanded from [sandbox/cenmap/misc/jquery.js]) is not a fileTRUE
REQUEST_FILENAME (value: [C:\Websites\default_https/sandbox/cenmap/misc/jquery.js]) expanded from [sandbox/cenmap/misc/jquery.js]) is not a directoryTRUE
REQUEST_FILENAME (value: [C:\Websites\default_https/sandbox/cenmap/misc/jquery.js]) expanded from [sandbox/cenmap/misc/jquery.js]) is an empty fileTRUE
REQUEST_URI (value: [C:\Websites\default_https//sandbox/cenmap/misc/jquery.js?v=1.4.4]) expanded from [/sandbox/cenmap/misc/jquery.js?v=1.4.4]) is not a fileTRUE
REQUEST_URI (value: [C:\Websites\default_https//sandbox/cenmap/misc/jquery.js?v=1.4.4]) expanded from [/sandbox/cenmap/misc/jquery.js?v=1.4.4]) is not a directoryTRUE
REQUEST_URI (value: [C:\Websites\default_https//sandbox/cenmap/misc/jquery.js?v=1.4.4]) expanded from [/sandbox/cenmap/misc/jquery.js?v=1.4.4]) is an empty fileTRUE
QUERY_STRING (value: [v=1.4.4]) does not match with [^q=.*] => TRUE
SCRIPT_FILENAME (value: [C:\Websites\default_https/sandbox/cenmap/misc/jquery.js]) expanded from [sandbox/cenmap/misc/jquery.js]) is not a fileTRUE
SCRIPT_FILENAME (value: [C:\Websites\default_https/sandbox/cenmap/misc/jquery.js]) expanded from [sandbox/cenmap/misc/jquery.js]) is not a directoryTRUE
SCRIPT_FILENAME (value: [C:\Websites\default_https/sandbox/cenmap/misc/jquery.js]) expanded from [sandbox/cenmap/misc/jquery.js]) is an empty fileTRUE
All the conditions are verified (TRUE).
Matching results:
$0=/sandbox/cenmap/misc/jquery.js
$1=misc/jquery.js
Replacing the virtual path with [/sandbox/cenmap/] => /sandbox/cenmap/
Adding the query string replacement [?q=$1] => /sandbox/cenmap/?q=misc/jquery.js
===> Internal redirection to /sandbox/cenmap/?q=misc/jquery.js |
Here are my concerns from the above situation.
1. On the 1st section, where URL=/sandbox/cenmap/?q=welcome_census_mapping_submission_facility, I am hence asking why this section has been entitled in its first line as:
| Code: | | Request URI=[/sandbox/cenmap/]: |
whereas in the actual variables,
| Code: | | REQUEST_URI=/sandbox/cenmap/?q=welcome_census_mapping_submission_facility |
is being displayed. This makes for a confusing debugging log tracing activity. Would you please make the section title congruent with the actual variable?
2. Moving on to the next section where REQUEST_URI=/sandbox/cenmap/misc/jquery.js?v=1.4.4. Note that this object (jquery.js) is an actual file sitting on my server "2014/01/16 03:43 AM 78,602 jquery.js". However, on Rule#2 under this same section, we see:
| Code: | | REQUEST_FILENAME (value: [C:\Websites\default_https/sandbox/cenmap/misc/jquery.js]) expanded from [sandbox/cenmap/misc/jquery.js]) is not a fileTRUE |
- which, I believe is incorrect. REQUEST_FILENAME is the relevant rewrite condition variable in my .htaccess file.
I am also wondering on the validity of the following test conditions:
| Code: | SCRIPT_FILENAME (value: [C:\Websites\default_https/sandbox/cenmap/misc/jquery.js]) expanded from [sandbox/cenmap/misc/jquery.js]) is not a fileTRUE
SCRIPT_FILENAME (value: [C:\Websites\default_https/sandbox/cenmap/misc/jquery.js]) expanded from [sandbox/cenmap/misc/jquery.js]) is an empty fileTRUE |
Am I correct in my assessment on this situation? Is this a manifestation of bugs in Abyss 2.9.0.1? Or am I implementing my rewrites and reading these logs wrongly? Kindly provide useful insights. Thanks!
_________________
 http://home.loloyd.com/ is online if the logo graphic at left is showing. |
|
| Back to top |
   |
 |
loloyd
-
Joined: 03 Mar 2006
Posts: 435
Location: Philippines
|
| Posted: Wed Apr 02, 2014 9:41 am Post subject: It's another case of virtual directories |
|
|
OK. I think something's wrong here. There's a problem with the server's expansion:
| Code: | | REQUEST_FILENAME (value: [C:\Websites\default_https/sandbox/cenmap/misc/jquery.js]) expanded from [sandbox/cenmap/misc/jquery.js]) is not a fileTRUE |
Actually, I have my "/sandbox" setup as a virtual path alias to somewhere else, and hence "C:\Websites\default_https/sandbox/cenmap/misc/jquery.js" can never resolve to the correct directory. Should not Abyss resolve the correct expansion for virtual directories?
Let's say my web root is "C:\Websites\default_https". If "/sandbox" is actually pointing to "D:\Projects\sandbox", shouldn't the expansion be made to accommodate virtual paths as well so that web requests like "sandbox/cenmap/misc/jquery.js" would properly expand to "D:\Projects\sandbox/cenmap/misc/jquery.js"?
_________________
http://home.loloyd.com/ is online if the logo graphic at left is showing. |
|
| Back to top |
|
|
loloyd
-
Joined: 03 Mar 2006
Posts: 435
Location: Philippines
|
| Posted: Fri Apr 25, 2014 7:01 am Post subject: |
|
|
The expansion of aliased items (virtual directories) in URL Rewrite seems bugged. Will Aprelium be fixing this for the next Abyss release?
_________________
http://home.loloyd.com/ is online if the logo graphic at left is showing. |
|
| Back to top |
|
|
aprelium-support
-
Joined: 20 Feb 2009
Posts: 356
|
| Posted: Fri Apr 25, 2014 11:39 am Post subject: |
|
|
| loloyd wrote: | | The expansion of aliased items (virtual directories) in URL Rewrite seems bugged. Will Aprelium be fixing this for the next Abyss release? |
So there is no bug here. Right now, URL Rewriting is performed very early in the processing pipeline of a request: it is actually being done before mapping aliases.
_________________
Support Team
Aprelium - http://www.aprelium.com |
|
| Back to top |
|
|
loloyd
-
Joined: 03 Mar 2006
Posts: 435
Location: Philippines
|
| Posted: Wed Aug 13, 2014 5:04 am Post subject: |
|
|
I feel that this is a bug.
Here is my rationale for my proposition why this is a bug.
1. I have setup "/sandbox" as a virtual directory alias to the local OS directory "D:\Projects\sandbox".
2. My web root sits at "C:\Websites\default_https".
3. The proper REQUEST_FILENAME expansion for requests like "https://loloyd/sandbox/index.php" should be "D:\Projects\sandbox\index.php".
4. As of my current Abyss version, the REQUEST_FILENAME expansion for requests like "https://loloyd/sandbox/index.php" goes to "C:\Websites\default_https/sandbox/index.php" - which is actually a non-existent and unresolvable file.
And besides, I also think that the expansion should follow the sub-directory hierarchy notation of the local OS, so if it's Windows, the expansion would replace all instances of forward slashes "/" to backward slashes "\".
_________________
http://home.loloyd.com/ is online if the logo graphic at left is showing. |
|
| Back to top |
|
|
admin
Site Admin
Joined: 03 Mar 2002
Posts: 1347
|
| Posted: Fri Oct 17, 2014 4:49 pm Post subject: |
|
|
loloyd,
URL rewriting doesn't play well with aliased paths. So it is highly recommended to not mix both.
_________________
Follow @abyssws on Twitter
Subscribe to our newsletter
_________________
Forum Administrator
Aprelium - https://aprelium.com |
|
| Back to top |
|
|
pkSML
-
Joined: 29 May 2006
Posts: 959
Location: Michigan, USA
|
| Posted: Sun Nov 30, 2014 11:54 pm Post subject: |
|
|
| aprelium-support wrote: | | Right now, URL Rewriting is performed very early in the processing pipeline of a request: it is actually being done before mapping aliases. |
Why not map aliases first? Is it for performance reasons? It would seem others would want to use aliases with URL rewriting.
_________________
Stephen
Need a LitlURL?
http://CodeBin.yi.org |
|
| Back to top |
|
|
|
