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:
WebCat2b13 Mac plugin - [sendmail] and checkboxes (1997)
Re:2nd WebCatalog2 Feature Request (1996)
NT Version on IIS 4.0 (1997)
Exclude by date - multiple (1997)
multiple search commands (1997)
New Plug-in and Type 11 errors (1997)
raw field names (2001)
[WebDNA] No more SQL in 7.1? (2012)
[WebDNA] Amazon EC2 (2009)
HELP WITH DATES (1997)
Mauthcapture vs mauthonly (2002)
Email Scavengers (2003)
Rhapsody? (1997)
[WebDNA] Brian Harrington (2019)
Exclamation point (1997)
Root Folder problems cont. (1998)
Listserver problem (1997)
AOL (1999)
[WebDNA] Permission Settings (2009)
range searching (1998)