Francesco,
Okay here is the thing: you keep using two servers to diagnose an API
which doesn't appear in any of the code you are using. Just use one page
on the server that you think does not work. You don't need to include
any other page, parse any other page or do anything fancy. If you do,
you
Francesco Petrarch wrote:
Ok, I got this, this time I really do, and it should be easily
replicated by anyone.
I have this filter:
ns_register_filter preauth GET /*.html decode_url
ns_register_filter preauth POST /*.html decode_url
ns_register_filter preauth HEAD /*.html decode_url
proc
I understand that on this issue my problem solving skills have been less then
perfect and have offered some incorrect assumptions, however, my last example
included in my previous message used exactly 1 server, not 2 and the problem
was 100% repeatable.
My original reasoning for using 2
Got it. you were close
ns_adp_return set the status to return, but still caused the next adp to fail,
so taking your code I altered it a bit...
proc decode_url { why } {
set page [ns_adp_parse -file /www/spells/template2.adp]
ns_return 200 text/html $page
ns_adp_exception state
Jeff Rogers wrote:
proc decode_url { why } {
set page [ns_adp_parse -file /www/website/template.adp]
ns_return 200 text/html $page
ns_adp_exception state
ns_log notice adp exception state is $state
catch {ns_adp_return}
return filter_return
}
Whoops, this won't
Jeff,
Thanks for that bit of help. As far as I can tell everything seems to
work correctly. I setup a slightly different test to demonstrate the
behavior.
Register filters in the private library:
proc ::test_adp_abort {arg why} {
switch -exact -- $arg {
file {
