Re: [AOLSERVER] hacking around
Ok, it's good that there are other devs reading, it means I can toss out ideas and get useful feedback on them :) Jim Davidson wrote: Howdy, I still watch the list but haven't had time to dig into the code in a long time -- maybe later this summer :) I unfortunately have more time to think about coding on my commute than actually coding. But like you, maybe sometime soon. Anyway, these connection filters are a bit confusing and not well documented -- my fault. Here I think it's ok to not call the filters again but it could go either way. If you update the code, you could make it configurable, default current behavior, to avoid breaking something that assumed the old behavior. In practice I don't think these filters were used very much -- I can only recall the access log modules and one other use in some obscure AOL internal module from years ago. I think there's some OpenACS folks reading at least intermittently, so this may be of interest. I get down into these filters trying to figure out why my OpenACS installation returned error pages for bad urls instead of the configured 404 page. What appears to be going on is that a preauth filter rp_filter is set up to do authentication and some other initialization (importantly, populating ad_conn values), while the main request processor is rp_handler which dispatches the request via a number of different mechanisms and if it fails all of those falls through to ns_returnnotfound, which does the internal 404 redirect. However, the 404 page will also get handled by rp_handler, but based on the values in ad_conn (specifically, extra_url) that are only set up in the preauth filter; if the filter is not run again then it tries to handle the internal 404 url based on the original url and fails again, until it hits the recursion limit and just given an error. (BTW, setting up a 500 error page here crashes the server by overflowing the stack.) This also makes it impossible to use acs-templating on the 404 or 500 error page. Changing the internal redirect logic to call the filters makes this apparently work cleanly in OpenACS. But I could also easily imagine a case where calling those filters twice would badly break things, so making it configurable with the old behavior as the default is probably the best approach. Alternately (if we were to rewind history) is would be useful to set the authorization proc to a tcl callback. There a C api to set it, but that's not exposed at the tcl level. -J -Jim On Jun 2, 2011, at 7:04 PM, Jeff Rogers wrote: Distracting myself with code diving, I found that internal redirects, implemented by Ns_ConnRedirect and as are used for among other things 404 and 500 error pages, work by changing the url, reauthorizing, and then running the request. However, it does not run preauth and postauth filters. This seems wrong to me, but it seems to have been this way forever. Does anyone have a reason why it shouldn't be changed to run those filters? -J PS: are any other developers even still reading this? -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email tolists...@listserv.aol.com 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 tolists...@listserv.aol.com 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 lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] hacking around
On Jun 6, 2011, at 11:31 AM, Jeff Rogers wrote: I get down into these filters trying to figure out why my OpenACS installation returned error pages for bad urls instead of the configured 404 page. What appears to be going on is that a preauth filter rp_filter is set up to do authentication and some other initialization (importantly, populating ad_conn values), while the main request processor is rp_handler which dispatches the request via a number of different mechanisms and if it fails all of those falls through to ns_returnnotfound, which does the internal 404 redirect. However, the 404 page will also get handled by rp_handler, but based on the values in ad_conn (specifically, extra_url) that are only set up in the preauth filter; if the filter is not run again then it tries to handle the internal 404 url based on the original url and fails again, until it hits the recursion limit and just given an error. (BTW, setting up a 500 error page here crashes the server by overflowing the stack.) This also makes it! impossible to use acs-templating on the 404 or 500 error page. Yes, this has been a known problem and known to be due to the fact that filter's not being run. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] hacking around
On Mon, Jun 06, 2011 at 11:31:02AM -0700, Jeff Rogers wrote: This also makes it impossible to use acs-templating on the 404 or 500 error page. As I vaguely recall from 10+ years ago, it can be done, although it's not obvious. I did it by dynamically calling the underlying acs-templating procs. In general, I don't think the ACS/OpenACS 4.x request processor design was EVER carefully thought out with respect to all of AOLserver's features and use cases. The OpenACS rp_* Tcl code just grabs control from the AOLserver mechanisms. That looked very much lot like the original developer simply did the obvious straightforward thing that would work for OpenACS. Works fine, but as others have commented here over the years, probably wasn't the optimal way to use the AOLserver tools. -- Andrew Piskorski a...@piskorski.com http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] hacking around
Don Baccus wrote: On Jun 6, 2011, at 11:31 AM, Jeff Rogers wrote: I get down into these filters trying to figure out why my OpenACS installation returned error pages for bad urls instead of the Yes, this has been a known problem and known to be due to the fact that filter's not being run. So you're saying I could have just asked? :) Well my question for now is, if this was fixed/changed in a way like I've suggested, how long would it be before OpenACS could take advantage of the change? I'm guessing it would need to be at least 2 releases before server requirements could be changed, but that estimate is based on policies I've seen elsewhere, not OpenACS specifically. Are there other aolserver bugs/inadequacies that openacs works around that could be improved? I know that back in the day ArsDigita contributes a number of patches to aolserver (or may have just distributed patches separately; I know that I had a server running 3.1+ad12 at one point). After all, aolserver is a fairly small ecosystem and I believe OpenACS represents a significant part of that, so it makes sense to have some cross-pollination (by which I don't mean adding OpenACS-specific functionality to aolserver, but rather adding/improving general functionality that OpenACS would benefit from). -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] hacking around
On Jun 6, 2011, at 2:08 PM, Jeff Rogers wrote: Well my question for now is, if this was fixed/changed in a way like I've suggested, how long would it be before OpenACS could take advantage of the change? Wouldn't it just work automagically if the filter were run and context set up properly by rp_filter? Are there other aolserver bugs/inadequacies that openacs works around that could be improved? Not that I'm aware of at this point, though Gustaf Neuman of U Wien might have something. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] hacking around
Don Baccus wrote: On Jun 6, 2011, at 2:08 PM, Jeff Rogers wrote: Well my question for now is, if this was fixed/changed in a way like I've suggested, how long would it be before OpenACS could take advantage of the change? Wouldn't it just work automagically if the filter were run and context set up properly by rp_filter? Hrm, I guess that's true for what I suggested (modulo a config file addition). I was thinking in the bigger context I suggested tho - if aolserver implemented a new feature that OpenACS could make use of (particularly in core packages), how many releases would need to go by before it could be used. As a contrived example, if authentication (in the sense of Ns_AuthorizeRequest) could be done by a tcl callback, then rp_filter could be a authorization proc instead of a preauth filter, but it would then be incompatible with a version of the server that did not support that. Of course, this is all theoretical right now. It would be a lot easier to reason about it if there was a real use case. -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] hacking around
On Jun 6, 2011, at 4:49 PM, Jeff Rogers wrote: Of course, this is all theoretical right now. It would be a lot easier to reason about it if there was a real use case. Yes, it is. There's very little development activity around OpenACS these days, and I can't think of anything in AOLserver that's begging for improvement from the point of view of the toolkit (contrary to an opinion stated in a previous post, the request processor implementation is efficient, and isn't an indication that the implementer didn't understand AOLserver, indeed filters are provided exactly so the kind of processing done in the request processor can be done). Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] hacking around
On Mon, Jun 06, 2011 at 05:31:44PM -0700, Don Baccus wrote: (contrary to an opinion stated in a previous post, the request processor implementation is efficient, and isn't an indication that the implementer didn't understand AOLserver, That isn't what I said, Don. There's nothing in particular wrong with the way the OpenACS request processor filter works, but I recall discussion by others here on the AOLserver list, years ago, about how it could, essentially, be made to play more nicely with other AOLserver filters, and why that might be useful. I don't recall the details, but their arguments seemed to make sense at the time. Clearly OpenACS didn't need any other special AOLserver filters so it was reasonable to do its request processor the way it still works today, rather than something more general which might look better from an AOLserver-centric rather than OpenACS-centric point of view. My point here was merely that I'm fairly sure that whoever implemented the ACS/OpenACS request processor approached the problem very much from the point of view of, AOLserver is just a tool to implement OpenACS; what's one good way to make it do what I want for OpenACS? Nothing wrong with that at all, but it has different implications than, I use this AOLserver tool in a lot of different environments, what seems to be the best way I can have it support what one of those environments, OpenACS, needs? -- Andrew Piskorski a...@piskorski.com http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] hacking around
On Jun 6, 2011, at 6:07 PM, Andrew Piskorski wrote: On Mon, Jun 06, 2011 at 05:31:44PM -0700, Don Baccus wrote: (contrary to an opinion stated in a previous post, the request processor implementation is efficient, and isn't an indication that the implementer didn't understand AOLserver, I don't recall the details I don't doubt this in the least ... Clearly OpenACS didn't need any other special AOLserver filters so it was reasonable to do its request processor the way it still works today, rather than something more general which might look better from an AOLserver-centric rather than OpenACS-centric point of view. You know, I'm involved with people doing RAILS work today, and I don't recall anyone making the argument that the platform should be more Apache-oriented rather than RAILS oriented, etc. Same with, say, Django or other web application platforms. My point here was merely that I'm fairly sure that whoever implemented the ACS/OpenACS request processor approached the problem very much from the point of view of, AOLserver is just a tool to implement OpenACS; what's one good way to make it do what I want for OpenACS? Ahh ... your point was that whoever did the work at aD was a good software engineer, an excellent one, a point you didn't make particularly clear in your first post. Well, I agree. Whoever wrote that code did a good job. Nothing wrong with that at all, but it has different implications than, I use this AOLserver tool in a lot of different environments, what seems to be the best way I can have it support what one of those environments, OpenACS, needs? arsDigita (which I was never associated with, and was never paid a dime from, and which pretty much hated me) was right to make this decision the way they did. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] hacking around
On Jun 6, 2011, at 12:25 PM, Andrew Piskorski wrote: In general, I don't think the ACS/OpenACS 4.x request processor design was EVER carefully thought out with respect to all of AOLserver's features and use cases. Or, in this case, didn't understand the bug that the internal redirects on various errors like 404 didn't run the filters. Of course, in AOLserver 3.0 (underwhich the rp was first written) perhaps AOLserver did ... I admit to being somewhat astonished by the lack of orthogonality when I figured this out in the AOLserver code. It wasn't documented, and actually, rather than being an example of the rp's design not being carefully thought out in regard to AOLserver's features, I'd say that the design exposed a bug. The OpenACS rp_* Tcl code just grabs control from the AOLserver mechanisms. And this is just stupid. If the AOLserver paradigm is that people shouldn't write filters, it should not provide the facility to write filters. QED and all that. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] hacking around
Don Baccus wrote: On Jun 6, 2011, at 12:25 PM, Andrew Piskorski wrote: In general, I don't think the ACS/OpenACS 4.x request processor design was EVER carefully thought out with respect to all of AOLserver's features and use cases. Or, in this case, didn't understand the bug that the internal redirects on various errors like 404 didn't run the filters. Of course, in AOLserver 3.0 (underwhich the rp was first written) perhaps AOLserver did ... I actually checked this before my initial post. It's been this way as far as SF CVS goes back. Which is why I'm trying to tread lightly and not break something that relies on the current behavior. I admit to being somewhat astonished by the lack of orthogonality when I figured this out in the AOLserver code. It wasn't documented, and actually, rather than being an example of the rp's design not being carefully thought out in regard to AOLserver's features, I'd say that the design exposed a bug. Could be a bug or a deliberate design decision. I recall one of the AOL devs (Jim and Dossy?) at one point say that the featureset was very much driven by internal AOL demands. Of course, that was then, this is now. AOL is no longer the driving force, or I don't think any force. And my first impression is to call this behavior a bug, because it makes one kind of request (internal redirects) act differently than a normal request, with no way to change that. Others may agree or disagree, which is that I'm trying to find out. And once that's clear, what to do about it. I think it should be fixed to treat all requests, internal and external, the same; but to be compatible this behavior should be switchable and off by default. I have a half-patch for this (it's not switchable yet) that I can clean up and commit sometime soon, if no one objects. The OpenACS rp_* Tcl code just grabs control from the AOLserver mechanisms. And this is just stupid. If the AOLserver paradigm is that people shouldn't write filters, it should not provide the facility to write filters. I got the impression (based on my reading alone, not talking to anyone about it) that the request processor was created largely to give more control (especially at the tcl level) than aolserver's native procs and filters allow. So for instance the order of execution of filters could be controlled rather than being executed in a strictly fifo by definition order. As with any implementation it was a choice; a different person might have patched the core to allow better control of filters, and another person might have felt that the existing builtins were good enough and relied more on them. No matter, it's there now and it works and no one is complaining about it. -J PS: I really wasn't trying to stir up any arguments, I just wanted to contribute something. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] hacking around
Hi Jeff, I read the lists to remind myself of the joy of working with a nicely threaded server and the awesome old-school OpenACS community. It's amazing how many ex-OpenACSers I have the pleasure of being colleagues and friends with in totally different areas of life :) Now, if I ever get back into a lot of server work I will finally implement a properly threaded Ruby AOLServer module (I had so much fun developing https://github.com/aufflick/nsperl2 ) but for now my coding is nearly all MacOS / iOS. It makes me feel warm and fuzzy just knowing that people are still using and developing AOLServer :) Cheers, Mark. -- Mark Aufflick http://mark.aufflick.com/about/contact http://pumptheory.com/about On Thu, Jun 2, 2011 at 6:04 PM, Jeff Rogers dv...@diphi.com wrote: Distracting myself with code diving, I found that internal redirects, implemented by Ns_ConnRedirect and as are used for among other things 404 and 500 error pages, work by changing the url, reauthorizing, and then running the request. However, it does not run preauth and postauth filters. This seems wrong to me, but it seems to have been this way forever. Does anyone have a reason why it shouldn't be changed to run those filters? -J PS: are any other developers even still reading this? -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com 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 lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] hacking around
Howdy, I still watch the list but haven't had time to dig into the code in a long time -- maybe later this summer :) Anyway, these connection filters are a bit confusing and not well documented -- my fault. Here I think it's ok to not call the filters again but it could go either way. If you update the code, you could make it configurable, default current behavior, to avoid breaking something that assumed the old behavior. In practice I don't think these filters were used very much -- I can only recall the access log modules and one other use in some obscure AOL internal module from years ago. -Jim On Jun 2, 2011, at 7:04 PM, Jeff Rogers wrote: Distracting myself with code diving, I found that internal redirects, implemented by Ns_ConnRedirect and as are used for among other things 404 and 500 error pages, work by changing the url, reauthorizing, and then running the request. However, it does not run preauth and postauth filters. This seems wrong to me, but it seems to have been this way forever. Does anyone have a reason why it shouldn't be changed to run those filters? -J PS: are any other developers even still reading this? -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com 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 lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] hacking around
Yes, but things have been really low volume ... ;) On 6/2/11 9:04 PM, Jeff Rogers wrote: PS: are any other developers even still reading this? -- Dossy Shiobara | He realized the fastest way to change do...@panoptic.com | is to laugh at your own folly -- then you http://panoptic.com/ | can let go and quickly move on. (p. 70) * WordPress * jQuery * MySQL * Security * Business Continuity * -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
