Re: [WebDNA] Bug in [thisurlplusget] on v7
This WebDNA talk-list message is from 2011
It keeps the original formatting.
numero = 107373
interpreted = N
texte = I think I found an important clue in a PHP / Lighttpd online reference ... PHP has a fuction called REQUEST_URI which does the same thing as [thisurlplusget] in WebDNA. They both grab the full URL that was requested, including the parameters after the question mark. So it seems that [thisurlplusget] is the only way WebDNA can access the URL parameters in a lighttpd error handler page! Note that when I access the error handler page directly -- rather than getting there by requesting a non-existing page -- the [formvariables] context works as expected. -------- Bottom line, when using lighttpd you'll need [thisurlplusget] if you want to access the URL parameters when the visitor tries to visit a page that does not exist in the specified location. Sincerely, Kenneth Grome > > So lighttpd does not work properly? > > It seems to be working fine for me. It always has, ever > since I started using it 2-3 years ago. > > > How do you know the error is with WebDNA then? > > Two points to consider here: > > 1- There is definitely a bug in [thisurlplusget] because > it appends "lusget]" to the end of the interpreted value > when it should not. This is an issue with a simple > workaround, so until the bug gets fixed I'm using the > first of these two workarounds: > > [getchars start=8&from=end][thisurlplusget][/getchars] > [middle endbefore=lusget][thisurlplusget][/middle] > > 2- Since [formvariables] fails to display the name=value > parameters that appear after the ? in the originally > requested URL, my first thought is that this is also a > bug. After all, shouldn't [formvariables] display these > name=value pairs? > > Maybe now! After all, this is a special situation in > which the SERVER (not WebDNA) redirects the request to > WebDNA's error page. So maybe, just maybe, these > name=value pairs are NOT being passed as "formvariables" > from lighttpd to WebDNA. If this is true, it would > explain why the [formvariables] context does not display > them. > > But if they are not formvariables, what are they??? They > are certainly being passed to the page somehow, because > [thisurlplusget] is displaying them. In fact, > [thisurlplusget] seems to be the ONLY way I can display > then in v7. So the big question for me is: How are > they getting there, and how can WebDNA access them > without using [thisurlplusget]? > > Or is this actually a bug in the formvariables context in > v7 after all? > > Chris, do you have any insights on this issue? > > Sincerely, > Kenneth Grome
Associated Messages, from the most recent to the oldest:
I think I found an important clue in a PHP / Lighttpd online reference ... PHP has a fuction called REQUEST_URI which does the same thing as [thisurlplusget] in WebDNA. They both grab the full URL that was requested, including the parameters after the question mark. So it seems that [thisurlplusget] is the only way WebDNA can access the URL parameters in a lighttpd error handler page! Note that when I access the error handler page directly -- rather than getting there by requesting a non-existing page -- the
[formvariables] context works as expected. -------- Bottom line, when using lighttpd you'll need [thisurlplusget] if you want to access the URL parameters when the visitor tries to visit a page that does not exist in the specified location. Sincerely, Kenneth Grome > > So lighttpd does not work properly? > > It seems to be working fine for me. It always has, ever > since I started using it 2-3 years ago. > > > How do you know the error is with WebDNA then? > > Two points to consider here: > > 1- There is definitely a bug in [thisurlplusget] because > it appends "lusget]" to the end of the interpreted value > when it should not. This is an issue with a simple > workaround, so until the bug gets fixed I'm using the > first of these two workarounds: > > [getchars start=8&from=end][thisurlplusget][/getchars] > [middle endbefore=lusget][thisurlplusget][/middle] > > 2- Since
[formvariables] fails to display the name=value > parameters that appear after the ? in the originally > requested URL, my first thought is that this is also a > bug. After all, shouldn't
[formvariables] display these > name=value pairs? > > Maybe now! After all, this is a special situation in > which the SERVER (not WebDNA) redirects the request to > WebDNA's error page. So maybe, just maybe, these > name=value pairs are NOT being passed as "formvariables" > from lighttpd to WebDNA. If this is true, it would > explain why the
[formvariables] context does not display > them. > > But if they are not formvariables, what are they??? They > are certainly being passed to the page somehow, because > [thisurlplusget] is displaying them. In fact, > [thisurlplusget] seems to be the ONLY way I can display > then in v7. So the big question for me is: How are > they getting there, and how can WebDNA access them > without using [thisurlplusget]? > > Or is this actually a bug in the formvariables context in > v7 after all? > > Chris, do you have any insights on this issue? > > Sincerely, > Kenneth Grome
Kenneth Grome
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:
What am I missing (1997)
Relay link (2002)
Message Boards (2003)
Mac 2.1b2 speed (1997)
Unix DB Permission Error (2002)
Emailer (WebCat2) (1997)
creating a ShipCosts database (1997)
Weird Math and SV Bad News (1997)
Frames and WebCat (1997)
WEBCAT HIERARCHY (1999)
WebCat2 as a chat server? (1997)
Further on formula.db failure to calculate shipCost (1997)
Shownext - am i missing something? (1998)
Separate SSL Server (1997)
[SearchString] problem with [search] context (1997)
Running 2 two WebCatalog.acgi's (1996)
Webstar 1.3.1 PPC (1997)
Re:Help name our technology! (1997)
Multiple adding (1997)
taxrate - off by 1 cent (1997)