Hi Jim, No one wants a flame war.
I would like a world class webserver that is protocol compliant because I believe that makes development easier, not harder, and it makes it easier for me to encourage clients to use it, and it makes it easier for clients to use it, and not worry why it's neither Apache, or IIS. I would like a webserver that doesn't have to come with a collection of developer caveats. I would love to see a relationship between the AOLserver staff and the community in which each side supports, benefits from, and respects each other. Regarding your specific points, 1. Though it may not be RFC compliant to do what it is doing, it will >still work on 95%+ of the browsers in use. I believe the trend is not just that IE is taking over the desktop, but also that small micro browsers are cropping up left and right on all sorts of devices and internet appliances. I am annoyed these days when my ericsson fails to properly surf yahoo's site. I suspect a bug in either my phone's browser or yahoo's server. >2. It is only an issue if the developer has a coding error. Except that as ad_returnredirect shows, most of those coding errors can be completely mediated by extending what ns_returnredirect does. Since ad_returnredirect demonstrates a wonderful prototype (if not the fix itself), and thus completes much of the development process (requirements, design, ...) why not extend ns_returnredirect to make the developers tasks easier are more likely to be correct? >3. Taken together, it is extremely unlikely to happen in practice. Gosh, my experience has always beeen that P(coding error) approaches 1 for any non-trivial program. And sadly, because of the nature of scripted web pages, where (page return) functionality is often duplicated on each and every page, this misuse of ns_returnredirect when it occurs at all, is likely to occur on many many pages of a website, since it is the result of an otherwise competent developer, not realizing what RFC behavior actually is. And of course, I encountered this by finding it throughout the ACS, an example of a non-trivial website developed by largely competent programmers. >4. Given that it is unlikely, and that AOL's server developer >resources are limited, how many resources should be used in making this >change, reviewing it, testing it, etc.? I would say "not many". I don't know how long it will take to implement a fix. Since no one came forward saying, "yes, but low priority due to our lack of resources", and since no one said, "yes, could you submit a patch", and since no one rejected it saying, "we believe this will take a week of developer time that we don't have", I find it difficult to address your question of cost benefit analysis. In general I think any afternoon spent towards making AOLserver a more RFC compliant server is an afternoon well spent towards client and developer acceptance of our server. Jerry ======================================================== Jerry Asher [EMAIL PROTECTED] 1678 Shattuck Avenue Suite 161 Tel: (510) 549-2980 Berkeley, CA 94709 Fax: (877) 311-8688
