Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite'
This WebDNA talk-list message is from 2012
It keeps the original formatting.
numero = 108156
interpreted = N
texte = > I have question, ideas, possible solutions... >=20 > but meanwhile, I really want to answer this one simple question: >=20 > * WHY, on my local Apache setup on MacOS 10.6 / Webdna 7, is = [thisurl] reflecting the *pre-RewriteRule* URL? * >=20 > I need to emulate this. >=20 > What do you advise for trying to accomplish this? Can you point in = the direction of an example line in .htaccess, if that is what we are = talking about? >=20 > And/Or, I might understand this better, if I could see an example: > "...send a 301 (permanently moved) in response to the rewrite.." Bill, (or anyone) you said,=20 > [snip] "Otherwise the rewrite is invisible to the browser" [snip] But AFAIK "invisible to the browser", does not necessarily mean = "invisible to webdna" (who knows what all really goes on server side? = Do we really know _for sure_?). =20 Please consider this: a (remote) URL loaded in the browser: http://myDomain.com/by_country/India/pgName/123/ffff/ddd This ^^^ is a PHP-built site which I am working on ... and I am using = the 'Code-Igniter' framework for only everything in the 'by_country/' = directory of that site. =20 The Code-Igniter framework depends on a mode_rewrite = .htaccess/RewriteRule to direct ALL traffic of a site (or directory, = like in my case) through the front controller that you tell it to use. = Here is the relevant part of my .htaccess file in the 'by_country/' = directory:
RewriteEngine On [snip] RewriteBase /by_country/ [snip] # Checks to see if the user is attempting to access a valid file, # such as an image or css document, if this isn't true it sends the # request to index.php RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php?/$1 [L] # If we don't have mod_rewrite installed, all 404's # can be sent to index.php, and everything works as normal. # Submitted by: ElliotHaughin ErrorDocument 404 /index.php =20 Everything works perfectly; The logic in my controller (and so PHP too, = in general) knows very well what was the original URL that was typed in = the browser, before the RewriteRule kicked in. So I speculate, "how?". In the PHP code I use to generate the HTML output for the browser, in my = controller-->View file, I added this code: echo 'SCRIPT_FILENAME=3D'.$_SERVER['SCRIPT_FILENAME'].'
'; echo 'PHP_SELF=3D'.$_SERVER['PHP_SELF'].'
'; echo 'REQUEST_URI=3D'.$_SERVER['REQUEST_URI'].'
'; ...which outputs this: = SCRIPT_FILENAME=3D/usr/home/myAcct/public_html/myDomain.com/by_country/ind= ex.php PHP_SELF=3D/by_country/index.php REQUEST_URI=3D/by_country/India/pgName/123/ffff/ddd So I think that perhaps that '$_SERVER['REQUEST_URI']' is how PHP = demonstrates to us that it knows what the URL was *before* the = RewriteRule, ... ...meanwhile I think perhaps webdna's '[thisurl]' (on the 2 remote = webdna 6 servers I tested today) is analogous to PHP's = '$_SERVER['PHP_SELF']', i.e. the result *after* the RewriteRule. =20 So then I think, "Can we have a webdna tag that is analogous to PHP's = '$_SERVER['REQUEST_URI']' ... which can output the URL as it was before = any RewriteRule, like PHP's '$_SERVER['REQUEST_URI']' does? But then I think, "Wait ! , we still have not addressed HOW, on my local = webdna 7 setup, [thisurl] is already behaving like PHP's = '$_SERVER['REQUEST_URI']' ! " How?! (I mean if the the RewriteRule is = supposed to be opaque to webdna, then how is my local webdna 7 seeing = the *original* URL?) Something is not consistent here. =20 I am totally guessing when I propose that it is because of the way = apache is configured (the mysterious black hole known as apache, that = even the server admins seem hesitant to mess with, let alone master). Clearly, PHP (running remotely and locally) can figure out what the URL = was before a RewriteRule.. and so can my local webdna 7 install. So = there must be a way to get the same behavior on webdna v.6 / v.7 ... = running on a remote server. I have a really sweet webdna framework that I just wrote which is = hinging on this... and would love to trade anything if I could get some = help to solve this. Thanks -Govinda=
Associated Messages, from the most recent to the oldest:
> I have question, ideas, possible solutions... >=20 > but meanwhile, I really want to answer this one simple question: >=20 > * WHY, on my local Apache setup on MacOS 10.6 / Webdna 7, is =
[thisurl] reflecting the *pre-RewriteRule* URL? * >=20 > I need to emulate this. >=20 > What do you advise for trying to accomplish this? Can you point in = the direction of an example line in .htaccess, if that is what we are = talking about? >=20 > And/Or, I might understand this better, if I could see an example: > "...send a 301 (permanently moved) in response to the rewrite.." Bill, (or anyone) you said,=20 > [snip] "Otherwise the rewrite is invisible to the browser" [snip] But AFAIK "invisible to the browser", does not necessarily mean = "invisible to webdna" (who knows what all really goes on server side? = Do we really know _for sure_?). =20 Please consider this: a (remote) URL loaded in the browser: http://myDomain.com/by_country/India/pgName/123/ffff/ddd This ^^^ is a PHP-built site which I am working on ... and I am using = the 'Code-Igniter' framework for only everything in the 'by_country/' = directory of that site. =20 The Code-Igniter framework depends on a mode_rewrite = .htaccess/RewriteRule to direct ALL traffic of a site (or directory, = like in my case) through the front controller that you tell it to use. = Here is the relevant part of my .htaccess file in the 'by_country/' = directory:
RewriteEngine On [snip] RewriteBase /by_country/ [snip] # Checks to see if the user is attempting to access a valid file, # such as an image or css document, if this isn't true it sends the # request to index.php RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php?/$1 [L] # If we don't have mod_rewrite installed, all 404's # can be sent to index.php, and everything works as normal. # Submitted by: ElliotHaughin ErrorDocument 404 /index.php =20 Everything works perfectly; The logic in my controller (and so PHP too, = in general) knows very well what was the original URL that was typed in = the browser, before the RewriteRule kicked in. So I speculate, "how?". In the PHP code I use to generate the HTML output for the browser, in my = controller-->View file, I added this code: echo 'SCRIPT_FILENAME=3D'.$_SERVER['SCRIPT_FILENAME'].'
'; echo 'PHP_SELF=3D'.$_SERVER['PHP_SELF'].'
'; echo 'REQUEST_URI=3D'.$_SERVER['REQUEST_URI'].'
'; ...which outputs this: = SCRIPT_FILENAME=3D/usr/home/myAcct/public_html/myDomain.com/by_country/ind= ex.php PHP_SELF=3D/by_country/index.php REQUEST_URI=3D/by_country/India/pgName/123/ffff/ddd So I think that perhaps that '$_SERVER['REQUEST_URI']' is how PHP = demonstrates to us that it knows what the URL was *before* the = RewriteRule, ... ...meanwhile I think perhaps webdna's '
[thisurl]' (on the 2 remote = webdna 6 servers I tested today) is analogous to PHP's = '$_SERVER['PHP_SELF']', i.e. the result *after* the RewriteRule. =20 So then I think, "Can we have a webdna tag that is analogous to PHP's = '$_SERVER['REQUEST_URI']' ... which can output the URL as it was before = any RewriteRule, like PHP's '$_SERVER['REQUEST_URI']' does? But then I think, "Wait ! , we still have not addressed HOW, on my local = webdna 7 setup,
[thisurl] is already behaving like PHP's = '$_SERVER['REQUEST_URI']' ! " How?! (I mean if the the RewriteRule is = supposed to be opaque to webdna, then how is my local webdna 7 seeing = the *original* URL?) Something is not consistent here. =20 I am totally guessing when I propose that it is because of the way = apache is configured (the mysterious black hole known as apache, that = even the server admins seem hesitant to mess with, let alone master). Clearly, PHP (running remotely and locally) can figure out what the URL = was before a RewriteRule.. and so can my local webdna 7 install. So = there must be a way to get the same behavior on webdna v.6 / v.7 ... = running on a remote server. I have a really sweet webdna framework that I just wrote which is = hinging on this... and would love to trade anything if I could get some = help to solve this. Thanks -Govinda=
Govinda
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
Error:Too many nested [xxx] contexts (1997)
[WebDNA] Wish list (2010)
WebCat b13 CGI -shownext- (1997)
Inaugural meeting of the 'Oceanic WebDNA Programmers (2004)
Price Not Appearing (2000)
Error.html (1997)
Extended [ConvertChars] (1997)
how do I delete 1 of 2 identical records? (2003)
Stinkin' [Referrer] (1998)
re: emailer prob (1998)
multiple databases (1997)
Upgrading old WebCat Database Files (1997)
Summing fields (1997)
template security preferences????? (1998)
using showpage and showcart commands (1996)
WebDNA problem (2006)
Authenticate (1999)
TCP/IP connect (1998)
2nd try:Webcat interfering with Webstar? (1998)
[OT] Robust order processing (2003)