Tagged 2.0
Hi, I've tagged 2.0 as STRIKER_2_0_51_RC1. I'll roll a tarball later on today for testing. Sander
Re: [proxy] New implementation ready for testing
Graham Leggett wrote: Mladen Turk wrote: Since we are (Henri and myself, not sure for JeanFrederic) not httpd commiters, I'm not sure how the proxy_ajp will get maintained, but we can always send patches :) I'm quite happy to maintain the code, and can chase up any patches you send through in the mean time, if others don't beat me to it. Well I certainly will continue to support at least the ajp13 protocol in jakarta-tomcat-connector :)
Smart filtering and mod_filter
I've made some further updates both to the code and documentation since posting. One change is to support inserting a harness anywhere in the filter chain. This addresses the point Graham raised about having two separate mechanisms: it means the old mechanism can be entirely replaced (provided of course I provide easy-reading howto upgrade documentation). I would find this easier if it were under CVS, and I'd like to put it under httpd CURRENT, at modules/experimental/mod_filter.c (plus the corresponding documentation pages, of course). That should help with integration ahead of 2.2, including test-driving with existing filter modules, and will make it easier to coordinate the API updates in util_filter. Is this something that wants a vote? Anyone else have strong feelings for or against putting mod_filter under CVS? -- Nick Kew
Re: Bug 18388: cookies
On Mon, 30 Aug 2004, Geoffrey Young wrote: [replying to my words - largely chopped] Perhaps a better approach to 304 headers would be to explicitly exclude entity headers as enumerated in rfc2616, rather than explicitly include non-entity headers? That means the default for proprietary extensions (which HTTP explicitly permits) becomes to allow them in a 304. fwiw, this was discussed a few times in the archives. the one that comes to mind for me is this from doug: http://marc.theaimsgroup.com/?l=apache-httpd-devm=99298523417784w=2 That thread seems to be the same basic issue, but with reference to RFC1945. 2616 includes additional explanation, and seems more clearly to support the view that not only cookies but arbitrary unknown headers (if any) should be allowed. In the bug report 18388, Ryan J Eberhard wrote: It is also important to note that all other major web servers (IIS, iPlanet, and Domino) will return Set-Cookie headers on a 304 status. I'm in no position to confirm or deny that, but it tends to support the proposition, and suggest that if it caused trouble in the Real World then we could expect to know about it. personally, I tend to see it more from doug and nick's perspective and would be inclined to fix a long-standing issue that never made sense to me, but roy wrote the book and has unique insight here, so... Hmm. Would proposing it in STATUS for a vote be appropriate here? I think if anyone wants to veto it, we should have a reason that addresses Doug's and Ryan's arguments on the record. -- Nick Kew
Re: Bug 18388: cookies
Personally, I think that if Roy said that it would cause non-compliance then, unless he changed his mind, that's good enough for me to veto any change that would add Set-Cookie. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Bug 18388: cookies
On Tue, 31 Aug 2004, Jim Jagielski wrote: Personally, I think that if Roy said that it would cause non-compliance then, unless he changed his mind, that's good enough for me to veto any change that would add Set-Cookie. I strongly agree. Roy? --Cliff
Re: Bug 18388: cookies
[sent this yesterday, but it bounced] personally, I tend to see it more from doug and nick's perspective and would be inclined to fix a long-standing issue that never made sense to me, but roy wrote the book and has unique insight here, so... Umm, not really -- cookies are just broken by design. That's why they aren't in HTTP/1.1 and why they are not listed in 304. However, it is kind of pointless to only partly implement them, so go ahead and add Set-Cookie and Set-Cookie2 to the 304 list. Both the original Netscape spec and RFC 2965 allow Set-Cookie* to be sent on any response and expect it to be passed along in a 304, so we might as well allow folks to do totally moronic things with cookies. Roy
Programming a timeout into Apache
Hi: I am adding code to Apache 2.0 to provide a timeout for all authenticated content. I have everything working, but because browsers use cached credentials, I cannot be sure that the user re-authenticated or the browser re-authenticated. I change the realm name and do a HTTP_UNAUTHORIZED response to trick the browser into prompting the user. However, if the user types the password in wrong or cancels the authentication process, I cant be sure that the next successful authentication came from my original HTTP_UNAUTHORIZED response or not. Are there any tricks that can be done like telling the browser to clear the password cache or have the browser return the realm name that its authenticating to? Any other ideas or approaches to this problem would be appreciated. Thanks, Brian S. Wallace Oak Ridge National Laboratory P. O. Box 2008, MS 6025 Oak Ridge, Tennessee 37831-6025 Voice (865) 576-3193 Fax (865) 241-4000
Re: Programming a timeout into Apache
On Tue, 31 Aug 2004, Wallace, Brian S. wrote: Are there any tricks that can be done like telling the browser to clear the password cache Not that I know. And this list is mrore for the development of apache so not sure if this is the right place. or have the browser return the realm name that it's authenticating to? Any other ideas or approaches to this problem would be appreciated. Approaches I've used: * prefix the path with a random string; and only ask for an auth beyond that string. Most browsers will not try to use the password; or happily flash the popup box when a new prefix is seen. The timeout is simply (in my case) based on an MD5 of a secret, the clients IP address, the time of issue followed by a plaintext time itself. When the timeout comes the module accepts the connection; accepts the password as usual but does a redirect to a new prefix. * use the password in a form to set a crypto cookie or forward to a random page (i.e. postfix with a /counter++) and ask auth there (digest perhaps). If you must do it as your own module you can rip some ideas out of the 2.0 code or out of http://www.apache.org/~dirkx/mod_auth_jabber/ * for the truly evil (and I've only done this only in intranet situation; not sure how wise this is on an internet); put in a wildcard DNS entry; use server alias and use trick a with a random prefix in the FQDN. This fixes the issue with some corperate IE vrsions which also offer up the NT real username/passwd unsolicited. Dw
Re: Programming a timeout into Apache
On Tue, 31 Aug 2004, Wallace, Brian S. wrote: Are there any tricks that can be done like telling the browser to clear the password cache or have the browser return the realm name that it's authenticating to? Any other ideas or approaches to this problem would be appreciated. The are many tricks depending on the specific version of the specific browser. There is no way that I know of to reliably instruct browsers to forget a password. A google search will find many discussions of this topic. If you need to provide a reliable logout, you need to role your own sessions using that broken thing we call cookies or some other session technique. Further discussion should go to [EMAIL PROTECTED] Joshua.
RE: Programming a timeout into Apache
Thanks to all, I will move the discussion to [EMAIL PROTECTED] -Original Message- From: Joshua Slive [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 31, 2004 2:37 PM To: [EMAIL PROTECTED] Subject: Re: Programming a timeout into Apache On Tue, 31 Aug 2004, Wallace, Brian S. wrote: Are there any tricks that can be done like telling the browser to clear the password cache or have the browser return the realm name that it's authenticating to? Any other ideas or approaches to this problem would be appreciated. The are many tricks depending on the specific version of the specific browser. There is no way that I know of to reliably instruct browsers to forget a password. A google search will find many discussions of this topic. If you need to provide a reliable logout, you need to role your own sessions using that broken thing we call cookies or some other session technique. Further discussion should go to [EMAIL PROTECTED] Joshua.
Re: Bug 18388: cookies
At 11:53 AM 8/31/2004, Cliff Woolley wrote: On Tue, 31 Aug 2004, Jim Jagielski wrote: Personally, I think that if Roy said that it would cause non-compliance then, unless he changed his mind, that's good enough for me to veto any change that would add Set-Cookie. I strongly agree. Roy? As Roy just stated, cookies aren't in RFC 2616. Go ahead and apply this fix - I understand both perspectives; cookies as connection/session/auth data, and cookies as content metadata. The specification is really lacking in definition/. Bill
