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 = 108149
interpreted = N
texte = --20cf303a31b1b9a36004b70f452a Content-Type: text/plain; charset=ISO-8859-1 The incoming http request goes: browser -> Internet -> server (machine) -> apache (web server responsible for port at IP address) -> webdna (assuming file extension under webdna control) I think you can control what the browser sees if you send a 301 (permanently moved) in response to the rewrite. Otherwise the rewrite is invisible to the browser. I'm just guessing here, but some rewrites should be known and others are for internal purposes only. Bill On Sat, Jan 21, 2012 at 12:40 PM, Govinda wrote: > >> When I put webdna's [thisurl] tag into a .dna template that webdna > parses.. then (desired behavior) the output of [thisurl] reflects the URL > that I actually typed in the browser.. and NOT where the RewriteRule > redirected the browser to. But on a friend's remote server, where we are > working together, the inverse is happening - i.e. the output of [thisurl] > reflects where the RewriteRule redirected the browser to, as opposed to the > URL that I actually typed in the browser (NOT desired behavior) . > > > > what is the WebDNA version of your friend's server? > > Try this: > > platform=unix-Macintosh OS X > version=6.0 > > > [function name=CALL_DOMAIN][return][listmimeheaders > name=host&exact=F][url][value][/url][/listmimeheaders][/return][/function] > > [CALL_DOMAIN] > > Thanks Chris :-) > ...but [listmimeheaders > name=host&exact=F][url][value][/url][/listmimeheaders] only returns the > *domain*, and not also any of the directories that come *after* the domain > in the URL... whereas [thisurl] does also return any of the directories > that come *after* the domain in the URL. I need the directories too. > > > > >> Does anyone know a way to cause the output of [thisurl] to always > reflect the URL that I actually type in the browser.. and NOT where the > RewriteRule redirects the browser to? > > > > i suppose it depends if the apache module mod_rewrite processes the URL > before or after WebDNA does > > If this is true, then: > > Do you know how to control when mod_rewrite kicks in? We could use some > help with this level of apache admin. Apparently, we want mod_rewrite to > kick in *after* webdna gets the file.. but at the moment the reverse is > happening. > > Or, wait a minute.. this makes no sense. If apache tried to hand the > file to webdna before mod_rewrite kicked in then I would not see anything > resembling my page in the browser because the URL is pointing to a > *non-existent* file. The fact that the file is non-exitant is the very > reason I want to use mod_rewrite. My RewriteRule causes the URL to become > re_written to point to a real existent webdna file. > > AFAICT mod_rewrite *has to be* (in both my local and remote cases) kicking > in before webdna gets the file.. because my file IS being parsed by webdna > and spitting out the expected dynamic HTML output... the only problem is > that in the remote-server case [thisurl] reflects the *post-RewriteRule* > URL, as opposed to the *pre-RewriteRule* URL. Maybe that is expected > behavior... but then why on my local setup does [thisurl] reflect the > *pre-RewriteRule* URL?! > > Would anyone be willing to setup up a test case and see what you find.. > set up mod_rewrite and a RewriteRule in .htaccess which points a sample URL > like this non-existent page: 'domain.com/testDIR_A/testPAGE_A.html' ... > to your existent page: 'domain.com/testDIR_B/testPAGE_B.html' page... > and then inspect the output of [thisurl] to see what you get. And while > reporting findings, please mention if your test was on your localhost > setup, or was it on a remote server? I would like to know the results of > both if possible. > > The results of all this is something I am trying to finish off in the next > couple days and share with the group here.. something nice and really > worthwhile. > > Thanks! > > -Govinda--------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > archives: http://mail.webdna.us/list/talk@webdna.us > Bug Reporting: support@webdna.us > --20cf303a31b1b9a36004b70f452a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The incoming http request goes:

browser -> Internet -= > server (machine) -> apache (web server responsible for port at IP a= ddress) -> webdna (assuming file extension under webdna control)

I think you can control what the browser sees if you se= nd a 301 (permanently moved) in response to the rewrite. =A0Otherwise the r= ewrite is invisible to the browser. =A0I'm just guessing here, but some= rewrites should be known and others are for internal purposes only. =A0

Bill

On Sat, Jan 21, = 2012 at 12:40 PM, Govinda <govinda.webdnatalk@gmail.com> wrote:
=
>> When I put webdna's [thisurl] tag into a .dn= a template that webdna parses.. then (desired behavior) the output of [this= url] reflects the URL that I actually typed in the browser.. and NOT where = the RewriteRule redirected the browser to. =A0But on a friend's remote = server, where we are working together, the inverse is happening - i.e. the = output of [thisurl] reflects where the RewriteRule redirected the browser t= o, as opposed to the URL that I actually typed in the browser (NOT desired = behavior) .
>
> what is the WebDNA version of your friend's server?
> Try this:

platform=3Dunix-Macintosh OS X
version=3D6.0

> [function name=3DCALL_DOMAIN][return][listmimeheaders name=3Dhost&= exact=3DF][url][value][/url][/listmimeheaders][/return][/function]
> [CALL_DOMAIN]

Thanks Chris =A0:-)
...but [listmimeheaders name=3Dhost&exact=3DF][url][value][/url][/listm= imeheaders] only returns the *domain*, and not also any of the directories = that come *after* the domain in the URL... =A0whereas [thisurl] does also r= eturn any of the directories that come *after* the domain in the URL. =A0 I= need the directories too.

>
>> Does anyone know a way to cause the output of [thisurl] to always = reflect the URL that I actually type in the browser.. and NOT where the Rew= riteRule redirects the browser to?
>
> i suppose it depends if the apache module mod_rewrite processes the UR= L before or after WebDNA does

If this is true, then:

Do you know how to control when mod_rewrite kicks in? =A0We could use some = help with this level of apache admin. =A0 Apparently, we want mod_rewrite t= o kick in *after* webdna gets the file.. but at the moment the reverse is h= appening.

Or, wait a minute.. =A0this makes no sense. =A0If =A0apache tried to hand t= he file to webdna before mod_rewrite kicked in then I would not see anythin= g resembling my page in the browser because the URL is pointing to a *non-e= xistent* file. =A0The fact that the file is non-exitant is the very reason = I want to use mod_rewrite. =A0 My RewriteRule causes the URL to become re_w= ritten to point to a real existent webdna file.

AFAICT mod_rewrite *has to be* (in both my local and remote cases) kicking = in before webdna gets the file.. because my file IS being parsed by webdna = and spitting out the expected dynamic HTML output... =A0the only problem is= that in the remote-server case [thisurl] reflects the *post-RewriteRule* U= RL, as opposed to the *pre-RewriteRule* URL. =A0Maybe that is expected beha= vior... but then why on my local setup does [thisurl] reflect the *pre-Rewr= iteRule* URL?!

Would anyone be willing to setup up a test case and see what you find.. =A0= set up mod_rewrite and a RewriteRule in .htaccess which points a sample UR= L like this non-existent page: =A0'domain.com/testDIR_A/testPAGE_A.html<= /a>' =A0... to your existent =A0page: 'domain.com/testDIR_B/testPAGE= _B.html' page... =A0and then inspect the output of [thisurl] to see= what you get. =A0And while reporting findings, please mention if your test= was on your localhost setup, or was it on a remote server? =A0I would like= to know the results of both if possible.

The results of all this is something I am trying to finish off in the next = couple days and share with the group here.. something nice and really worth= while.

Thanks!

-Govinda---------------------------------------------------------
This message is sent to you becaus= e you are subscribed to
the mailing list <talk@webdna.us&g= t;.
To unsubscribe, E-mail to: <talk= -leave@webdna.us>
archives: http://mail.webdna.us/list/talk@webdna.us
Bug Reporting: support@webdna.us

--20cf303a31b1b9a36004b70f452a-- Associated Messages, from the most recent to the oldest:

    
  1. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (Tom Duke 2012)
  2. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (Govinda 2012)
  3. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (Tom Duke 2012)
  4. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (Govinda 2012)
  5. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (William DeVaul 2012)
  6. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (Tom Duke 2012)
  7. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (Govinda 2012)
  8. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (William DeVaul 2012)
  9. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (Govinda 2012)
  10. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (Govinda 2012)
  11. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (William DeVaul 2012)
  12. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (Govinda 2012)
  13. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (Tom Duke 2012)
  14. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (Govinda 2012)
  15. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (William DeVaul 2012)
  16. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (William DeVaul 2012)
  17. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (Donovan Brooke 2012)
  18. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (Govinda 2012)
  19. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (Donovan Brooke 2012)
  20. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (William DeVaul 2012)
  21. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (Govinda 2012)
  22. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (Donovan Brooke 2012)
  23. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (Govinda 2012)
  24. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (Govinda 2012)
  25. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (William DeVaul 2012)
  26. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (Govinda 2012)
  27. Re: [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (christophe.billiottet@webdna.us 2012)
  28. [WebDNA] behavior of [thisurl] in the context of 'mod_rewrite' (Govinda 2012)
--20cf303a31b1b9a36004b70f452a Content-Type: text/plain; charset=ISO-8859-1 The incoming http request goes: browser -> Internet -> server (machine) -> apache (web server responsible for port at IP address) -> webdna (assuming file extension under webdna control) I think you can control what the browser sees if you send a 301 (permanently moved) in response to the rewrite. Otherwise the rewrite is invisible to the browser. I'm just guessing here, but some rewrites should be known and others are for internal purposes only. Bill On Sat, Jan 21, 2012 at 12:40 PM, Govinda wrote: > >> When I put webdna's [thisurl] tag into a .dna template that webdna > parses.. then (desired behavior) the output of [thisurl] reflects the URL > that I actually typed in the browser.. and NOT where the RewriteRule > redirected the browser to. But on a friend's remote server, where we are > working together, the inverse is happening - i.e. the output of [thisurl] > reflects where the RewriteRule redirected the browser to, as opposed to the > URL that I actually typed in the browser (NOT desired behavior) . > > > > what is the WebDNA version of your friend's server? > > Try this: > > platform=unix-Macintosh OS X > version=6.0 > > > [function name=CALL_DOMAIN][return][listmimeheaders > name=host&exact=F][url][value][/url][/listmimeheaders][/return][/function] > > [CALL_DOMAIN] > > Thanks Chris :-) > ...but [listmimeheaders > name=host&exact=F][url][value][/url][/listmimeheaders] only returns the > *domain*, and not also any of the directories that come *after* the domain > in the URL... whereas [thisurl] does also return any of the directories > that come *after* the domain in the URL. I need the directories too. > > > > >> Does anyone know a way to cause the output of [thisurl] to always > reflect the URL that I actually type in the browser.. and NOT where the > RewriteRule redirects the browser to? > > > > i suppose it depends if the apache module mod_rewrite processes the URL > before or after WebDNA does > > If this is true, then: > > Do you know how to control when mod_rewrite kicks in? We could use some > help with this level of apache admin. Apparently, we want mod_rewrite to > kick in *after* webdna gets the file.. but at the moment the reverse is > happening. > > Or, wait a minute.. this makes no sense. If apache tried to hand the > file to webdna before mod_rewrite kicked in then I would not see anything > resembling my page in the browser because the URL is pointing to a > *non-existent* file. The fact that the file is non-exitant is the very > reason I want to use mod_rewrite. My RewriteRule causes the URL to become > re_written to point to a real existent webdna file. > > AFAICT mod_rewrite *has to be* (in both my local and remote cases) kicking > in before webdna gets the file.. because my file IS being parsed by webdna > and spitting out the expected dynamic HTML output... the only problem is > that in the remote-server case [thisurl] reflects the *post-RewriteRule* > URL, as opposed to the *pre-RewriteRule* URL. Maybe that is expected > behavior... but then why on my local setup does [thisurl] reflect the > *pre-RewriteRule* URL?! > > Would anyone be willing to setup up a test case and see what you find.. > set up mod_rewrite and a RewriteRule in .htaccess which points a sample URL > like this non-existent page: 'domain.com/testDIR_A/testPAGE_A.html' ... > to your existent page: 'domain.com/testDIR_B/testPAGE_B.html' page... > and then inspect the output of [thisurl] to see what you get. And while > reporting findings, please mention if your test was on your localhost > setup, or was it on a remote server? I would like to know the results of > both if possible. > > The results of all this is something I am trying to finish off in the next > couple days and share with the group here.. something nice and really > worthwhile. > > Thanks! > > -Govinda--------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > archives: http://mail.webdna.us/list/talk@webdna.us > Bug Reporting: support@webdna.us > --20cf303a31b1b9a36004b70f452a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The incoming http request goes:

browser -> Internet -= > server (machine) -> apache (web server responsible for port at IP a= ddress) -> webdna (assuming file extension under webdna control)

I think you can control what the browser sees if you se= nd a 301 (permanently moved) in response to the rewrite. =A0Otherwise the r= ewrite is invisible to the browser. =A0I'm just guessing here, but some= rewrites should be known and others are for internal purposes only. =A0

Bill

On Sat, Jan 21, = 2012 at 12:40 PM, Govinda <govinda.webdnatalk@gmail.com> wrote:
=
>> When I put webdna's [thisurl] tag into a .dn= a template that webdna parses.. then (desired behavior) the output of [this= url] reflects the URL that I actually typed in the browser.. and NOT where = the RewriteRule redirected the browser to. =A0But on a friend's remote = server, where we are working together, the inverse is happening - i.e. the = output of [thisurl] reflects where the RewriteRule redirected the browser t= o, as opposed to the URL that I actually typed in the browser (NOT desired = behavior) .
>
> what is the WebDNA version of your friend's server?
> Try this:

platform=3Dunix-Macintosh OS X
version=3D6.0

> [function name=3DCALL_DOMAIN][return][listmimeheaders name=3Dhost&= exact=3DF][url][value][/url][/listmimeheaders][/return][/function]
> [CALL_DOMAIN]

Thanks Chris =A0:-)
...but [listmimeheaders name=3Dhost&exact=3DF][url][value][/url][/listm= imeheaders] only returns the *domain*, and not also any of the directories = that come *after* the domain in the URL... =A0whereas [thisurl] does also r= eturn any of the directories that come *after* the domain in the URL. =A0 I= need the directories too.

>
>> Does anyone know a way to cause the output of [thisurl] to always = reflect the URL that I actually type in the browser.. and NOT where the Rew= riteRule redirects the browser to?
>
> i suppose it depends if the apache module mod_rewrite processes the UR= L before or after WebDNA does

If this is true, then:

Do you know how to control when mod_rewrite kicks in? =A0We could use some = help with this level of apache admin. =A0 Apparently, we want mod_rewrite t= o kick in *after* webdna gets the file.. but at the moment the reverse is h= appening.

Or, wait a minute.. =A0this makes no sense. =A0If =A0apache tried to hand t= he file to webdna before mod_rewrite kicked in then I would not see anythin= g resembling my page in the browser because the URL is pointing to a *non-e= xistent* file. =A0The fact that the file is non-exitant is the very reason = I want to use mod_rewrite. =A0 My RewriteRule causes the URL to become re_w= ritten to point to a real existent webdna file.

AFAICT mod_rewrite *has to be* (in both my local and remote cases) kicking = in before webdna gets the file.. because my file IS being parsed by webdna = and spitting out the expected dynamic HTML output... =A0the only problem is= that in the remote-server case [thisurl] reflects the *post-RewriteRule* U= RL, as opposed to the *pre-RewriteRule* URL. =A0Maybe that is expected beha= vior... but then why on my local setup does [thisurl] reflect the *pre-Rewr= iteRule* URL?!

Would anyone be willing to setup up a test case and see what you find.. =A0= set up mod_rewrite and a RewriteRule in .htaccess which points a sample UR= L like this non-existent page: =A0'domain.com/testDIR_A/testPAGE_A.html<= /a>' =A0... to your existent =A0page: 'domain.com/testDIR_B/testPAGE= _B.html' page... =A0and then inspect the output of [thisurl] to see= what you get. =A0And while reporting findings, please mention if your test= was on your localhost setup, or was it on a remote server? =A0I would like= to know the results of both if possible.

The results of all this is something I am trying to finish off in the next = couple days and share with the group here.. something nice and really worth= while.

Thanks!

-Govinda---------------------------------------------------------
This message is sent to you becaus= e you are subscribed to
the mailing list <talk@webdna.us&g= t;.
To unsubscribe, E-mail to: <talk= -leave@webdna.us>
archives: http://mail.webdna.us/list/talk@webdna.us
Bug Reporting: support@webdna.us

--20cf303a31b1b9a36004b70f452a-- William DeVaul

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:

Security Issues and WebCommerce Solution (1997) RE: AccountAuthorizer doesn't seem to work (1997) append=T problem (1998) Maximum characters in header? (1999) WCS Newbie question (1997) Trouble with [fileinfo] (2004) Queertrons? (1997) Add - optional parameters textA=.... (1997) WebCat2b13MacPlugIn - More limits on [include] (1997) [WebDNA] remove preceding zero (2016) Fuzzy on [url] context (1998) [TaxableTotal] - not working with AOL and IE (1997) Security Issue (2000) WCS Newbie question (1997) Echo (2004) shipping costs (2000) Errata: WCS Newbie question (1997) WebDNA for Dummies (was: WebDNA portability) (2007) ConvertChars? (1998) Mac app. that converts e-mails (2000)