There are a couple things about this I'm still curious about:
1. What is the conn argument in ns_register_filter { conn what why } for? It provides a value like "cns0". Is this the extent of the "connection information" or is it a key to something? Absence of it does not prevent ns_conn from being used within the proc.
2. Why does [ns_conn host] used within the filter procedure return "" while [ns_conn url] returns the proper value?
Also, is there a reason this page of the new Tcl API docs is essentially empty?
http://dev.aolserver.com/wiki/Ns_register_filter
Information about ns_register_filter is still available at (old):
http://aolserver.sourceforge.net/docs/devel/tcl/api/general.html#ns_register_filter
http://www.aolserver.com/docs/devel/tcl/api/general.html#ns_register_filter
Eric Lee
At 11:54 AM 11/27/2008, you wrote:
Eric,
You really should be using ns_register_filter instead of ns_return_proc.
ns_register_filter when method URLpattern myScript ?args?proc myScript {?conn? args why} { # Do stuff... }
With ns_register_proc you intercept all matching URLs and *you* must provide valid responses.
With ns_register_filter you intercept all matching URLs (as with ns_register_proc), but if you don't want to handle the response yourself because the Host header doesn't match, you simply "return filter_ok" and the server continues to handle the response normally.
When the Host header does match, your proc would do the redirect or the ns_return or ns_write back to the client and then do a "return filter_return" so that the server doesn't continue to process the connection itself.
/s.
On Nov 27, 2008, at 10:53 AM, Eric Lee wrote:
Thanks for the tip about ns_conn headers, which gets me over the immediate problem.
My proc is now able to detect a host and ns_returnredirect successfully.
However if the test for that host fails the proc now returns nothing, i.e. a page of 0 bytes. What I want it do is just return the page requested, i.e. just treat the request in the normal way.
If I ns_returnredirect to the original location it gets into a loop (four requests in access.log) and the browser says:
"Firefox has detected that the server is redirecting the request for this address in a way that will never complete."
What is the correct way to handle this? Does the proc need to return the entire original page? Would that be [ns_conn content] or is there more to it than that? The result should be transparent, as though there were no registered proc involved.
Again, I wonder whether my approach to the initial problem is right.
I'm using AOLserver 4.0.10
Eric
-- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
-- AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
