DO NOT REPLY [Bug 33880] New: - Only URIs that map to files can be Executed
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33880.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33880
Summary: Only URIs that map to files can be Executed
Product: Apache mod_aspdotnet
Version: 2.0.0
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P4
Component: mod_aspdotnet
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I do all my URI rewriting and some custom URI handling inside my ASP.Net
Application. My site is composed of URIs that do not map to the file system so I
automatically get a 404 Error and the URI is never past to the ASP.Net Engine.
The following should be removed or modified from mod_aspdotnet.cpp (Line
403-406) as ASP.Net has its own error handling and it seems to me Apache can
pre-determine file or URI validity before passing the request:
if (r-finfo.filetype != APR_REG) {
ap_log_rerror(APLOG_MARK, APLOG_ERR|APLOG_NOERRNO, 0, r,
mod_aspdotnet: File not found or unable to stat: %s,
r-filename);
return HTTP_NOT_FOUND;
}
After commenting out and recompiling most of my application works fine now.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
Re: [VOTE] 2.1.3 as beta
At 07:22 AM 3/6/2005, Sander Striker wrote: I assume we are in agreement that the current AAA discussion shouldn't hold up moving to 2.2 either. Absolutely it does. Either 2.1-dev has made implementing this worse (my essentially workable proposal for 2.0 would no longer work at all, with no workaround) or 2.1-dev has made implementing such a feature possible, even trivial, even if it's not part of the httpd-2.2 core. Suggesting we push out 2.2 'as is, whatever' would be like having shoved out either Ryan's or Greg's original filter stack without the group coming to concensus (and best of breed solution.) I'm not saying we need to have this module. I'm asking if our new auth framework is worse or better than yesterday's for folks to build upon it. I'm sensing from comments that we've created a more complex structure which is harder to work with, but might not quite solve real world problems. If that's true (I'm +/-0 on deciding until I work this into 2.1-dev auth) then I'm one -1 on 2.2.0. The point to 2.2 is we are doing things that 2.0 couldn't. Either we have added such things well, or poorly. Only alphas in the hands of module authors tell us the answer to this. [For that matter, something somewhere needs to attract our module community to investigate, I don't think we successfully have engaged them. Not even some high level what's changed exists today other than good old CHANGES.txt.] That said - -nothing- should ever hold up 2.1.x alpha anytime someone has the energy to run with the ball!
Re: Multiple AAA providers
At 12:03 PM 3/6/2005, Justin Erenkrantz wrote: On Sat, Mar 05, 2005 at 10:59:30PM -0600, William A. Rowe, Jr. wrote: Ok, as Justin and I are in significant disagreement ... to summarize; we (collectively) would like to see some mechanism for multiple configurations of the same 'provider' (defined above). There are logically three places this can happen, so as a straw poll, would those interested in *coding* auth schemas please vote (end users, our choice will be transparent enough to you that we prefer the developers to indicate their preferences.) [ ] Implement in each provider (e.g. mod_authnz_ldap, mod_authn_file) Different AuthLdapConfig xxx AuthFileConfig zzz sections [ ] Implement in each scheme (e.g. basic, digest) Different AuthBasicConfig xxx AuthDigestConfig zzz sections [ ] Implement globally across schemes and providers Single AuthConfig xxx directive, but as it's not in the scheme which iterates the providers, control isn't as fine-grained. These choices overlook Brad's suggestion, which I still think is the best: [ ] Implement across providers Single AuthProviderAlias real-provider-name alias directive. I did not overlook it. What layer do you propose to code it at?
handler per extension
Hi all, Is there a way to set up (in httpd.conf) a content-handler module to be executed only for a specific extension? More clear, I have a mod_abc.c. I have to test if the request_rec *r-filename ends with .abc or I can set up my module in httpd.conf, by specifying the extension .abc? --- Lszl Graf
Re: handler per extension
Laszlo wrote: Hi all, Is there a way to set up (in httpd.conf) a content-handler module to be executed only for a specific extension? More clear, I have a mod_abc.c. I have to test if the request_rec *r-filename ends with .abc or I can set up my module in httpd.conf, by specifying the extension .abc? --- Lszl Graf Laszlo, This is a developers mailing list, not a place to ask for server configuration help. I think what your looking for is here: http://httpd.apache.org/docs-2.0/mod/mod_mime.html#addhandler See the default httpd.conf for several more examples. Bill
Re: Multiple AAA providers
On Mon, Mar 07, 2005 at 12:16:05AM -0600, William A. Rowe, Jr. wrote: These choices overlook Brad's suggestion, which I still think is the best: [ ] Implement across providers Single AuthProviderAlias real-provider-name alias directive. I did not overlook it. What layer do you propose to code it at? Did you forget my reply to Brad? I said that it'd be a module that exposes 'fake' new providers that merges in the appropriate per_dir_config before calling the real auth providers. I have not yet heard a reason why this would be an unsatisfactory solution. -- justin
Re: [VOTE] 2.1.3 as beta
On Mon, Mar 07, 2005 at 12:19:45AM -0600, William A. Rowe, Jr. wrote: At 07:22 AM 3/6/2005, Sander Striker wrote: I assume we are in agreement that the current AAA discussion shouldn't hold up moving to 2.2 either. Absolutely it does. Either 2.1-dev has made implementing this worse (my essentially workable proposal for 2.0 would no longer work at all, with no workaround) or 2.1-dev has made implementing such a feature possible, even trivial, even if it's not part of the httpd-2.2 core. Suggesting we push out 2.2 'as is, whatever' would be like having shoved out either Ryan's or Greg's original filter stack without the group coming to concensus (and best of breed solution.) I believe that analogy is completely without merit. The filter stack is at the heart of httpd's module design. The AAA functionality that is being discussed is relatively minor and the specific issue that has been raised has *never* been present before. When we come to agreement upon a solution for the AAA issue, then, per my proposal previously sent to [EMAIL PROTECTED], with 3 +1s we can change the API in the beta series. Yet, I don't believe *any* proposal or suggestion in the AAA threads so far makes changes the API in any way - it only adds functionality. Currently, we are being held up by gunpoint because you want to wait for a perfect beta. By definition, a perfect release should be a GA not a beta! So, I reiterate that this one minor issue should not be holding us up from a beta. This AAA code has been in the tree for *years* and you are just now complaining about a feature that has never existed? I kindly ask that you please stop getting in the way of forward progress. -- justin
Re: Multiple AAA providers
I believe that we are talking about coding at the provider layer (ldap, file, etc.). The problem here is that I am not sure what the following means: [ ] Implement globally across schemes and providers Single AuthConfig xxx directive, but as it's not in the scheme which iterates the providers, control isn't as fine-grained. But I do know what this means: [ ] Implement across providers Single AuthProviderAlias real-provider-name alias directive. If they are saying the same thing then we might all be on the same page. Now would be a great time to have one of those white board discussions like we have at ApacheCon :). I would like to see us implement a syntax that can be reused as I suggested earlier. An AuthProviderAlias ... tag would allow for that. I am -1 to Bill's original proposal mainly because each use of an auth module requires that it be reconfigured within it's Location even if the configurations across Locations are identical. If Bill's original proposal was reworked to pull the AuthConfig out of the Location scope and allow it to be reused as an alias, then I am +1. Brad [EMAIL PROTECTED] Sunday, March 06, 2005 11:16 PM At 12:03 PM 3/6/2005, Justin Erenkrantz wrote: On Sat, Mar 05, 2005 at 10:59:30PM -0600, William A. Rowe, Jr. wrote: Ok, as Justin and I are in significant disagreement ... to summarize; we (collectively) would like to see some mechanism for multiple configurations of the same 'provider' (defined above). There are logically three places this can happen, so as a straw poll, would those interested in *coding* auth schemas please vote (end users, our choice will be transparent enough to you that we prefer the developers to indicate their preferences.) [ ] Implement in each provider (e.g. mod_authnz_ldap, mod_authn_file) Different AuthLdapConfig xxx AuthFileConfig zzz sections [ ] Implement in each scheme (e.g. basic, digest) Different AuthBasicConfig xxx AuthDigestConfig zzz sections [ ] Implement globally across schemes and providers Single AuthConfig xxx directive, but as it's not in the scheme which iterates the providers, control isn't as fine-grained. These choices overlook Brad's suggestion, which I still think is the best: [ ] Implement across providers Single AuthProviderAlias real-provider-name alias directive. I did not overlook it. What layer do you propose to code it at?
Host and Type Container
Any thoughts about having two new config containers like these? Host and HostMatch Only apply config when ap_get_server_name(r) matches the directive. This could go after we walk the location. I have some hacks in some modules where the same Virtual server answers for multiple names but must act slightly different for some of them. Type and TypeMatch Only apply when r-content_type matches. This can be done, sort of, now but it is very awkward. Any thoughts? I can do a patch if anyone thinks it will be worth the time. Otherwise, I'll keep my my own hacks in my modules. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: [VOTE] 2.1.3 as beta
William A. Rowe, Jr. wrote: At 07:22 AM 3/6/2005, Sander Striker wrote: I assume we are in agreement that the current AAA discussion shouldn't hold up moving to 2.2 either. Absolutely it does. Either 2.1-dev has made implementing this worse (my essentially workable proposal for 2.0 would no longer work at all, with no workaround) or 2.1-dev has made implementing such a feature possible, even trivial, even if it's not part of the httpd-2.2 core. Suggesting we push out 2.2 'as is, whatever' would be like having shoved out either Ryan's or Greg's original filter stack without the group coming to concensus (and best of breed solution.) I'm not saying we need to have this module. I'm asking if our new auth framework is worse or better than yesterday's for folks to build upon it. I disagree. The current authentication in 2.1 is far far better than what 2.0 has. I have been using it in production variations for over 2 years now. Just the ability to use any authentication backend with Digest is a huge improvement. I'm sensing from comments that we've created a more complex structure which is harder to work with, but might not quite solve real world problems. If that's true (I'm +/-0 on deciding until I work this into 2.1-dev auth) then I'm one -1 on 2.2.0. This whole discussion is about a feature that has never existed before, and there isn't a patch for it yet. I believe the best method is to attack it at the point of least work, and if it ends up being good, look at extending it to everything. I think it should be hacked into mod_authnz_ldap, and if it works, then work can be done to generalize it to all the authnz modules. Right now we really don't know what is required to get it done. It is all just mailing list talk and theory. I do not believe it is appropriate to threaten a -1 veto on 2.2.0 for this issue. Its not a regression, its not something we have a patch for, its something that didn't exist a week ago. The point to 2.2 is we are doing things that 2.0 couldn't. Either we have added such things well, or poorly. Only alphas in the hands of module authors tell us the answer to this. [For that matter, something somewhere needs to attract our module community to investigate, I don't think we successfully have engaged them. Not even some high level what's changed exists today other than good old CHANGES.txt.] Alphas are generally worthless, as they are currently released, imho. We need to get to 'beta' and put it on our front page, get slashdotted, and send out announcement emails. That said - -nothing- should ever hold up 2.1.x alpha anytime someone has the energy to run with the ball! I am discouraged from trying to RM one, just from the knowledge that it will get a -1 veto, before I even roll it. -Paul
Re: Host and Type Container
Brian Akins wrote: Any thoughts about having two new config containers like these? Host and HostMatch Only apply config when ap_get_server_name(r) matches the directive. This could go after we walk the location. +1, in concept. I just was looking at the ap_get_server_name() function, and I didn't like how it behaves when UseConicalName is 'on'. It currently will return 'r-server-server_hostname'. This makes it hard for a dynamic vhosting module to set it per-request. If we copied the r-server-server_hostname into r-hostname when the request was created, then modules could easily override r-hostname. I have some hacks in some modules where the same Virtual server answers for multiple names but must act slightly different for some of them. Type and TypeMatch Hmm. Less sure about this one. It seems like it overlaps with other things like AddOutputFilterbyType, but, it might be a better way to handle it anyways: Type application/xml AddOutputFilter XSLT;DEFLATE TransformOptions +ApacheFS /Type I am already sort of liking it... -Paul
Re: [VOTE] 2.1.3 as beta
On Mar 7, 2005, at 1:19 AM, William A. Rowe, Jr. wrote: At 07:22 AM 3/6/2005, Sander Striker wrote: I assume we are in agreement that the current AAA discussion shouldn't hold up moving to 2.2 either. Absolutely it does. Either 2.1-dev has made implementing this worse (my essentially workable proposal for 2.0 would no longer work at all, with no workaround) or 2.1-dev has made implementing such a feature possible, even trivial, even if it's not part of the httpd-2.2 core. Suggesting we push out 2.2 'as is, whatever' would be like having shoved out either Ryan's or Greg's original filter stack without the group coming to concensus (and best of breed solution.) Bill's point, and it's valid, is whether or not the AAA framework is robust enough that we can push 2.2 with a good warm and fuzzy feeling that any fixes or improvements to it won't cause an API break (Justin does allude to this). Sure, API breaks can happen within and between Betas, but they should be very rare (IMO). I also don't see anything in the discussion currently which would lead me to believe that the API we have isn't adequate (at least) to do what we need done. I vote +1 for a beta.
Re: Host and Type Container
Paul Querna wrote: I just was looking at the ap_get_server_name() function, and I didn't like how it behaves when UseConicalName is 'on'. It currently will return 'r-server-server_hostname'. This makes it hard for a dynamic vhosting module to set it per-request. If we copied the r-server-server_hostname into r-hostname when the request was created, then modules could easily override r-hostname. But that kind of defeats the whole concept of UCN On, doesn't it? Or at least blurs the meaning... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: worker MPM: it sucks to have minimal MaxSpareThreads
On Mar 4, 2005, at 12:08 PM, Jeff Trawick wrote: Any comments on these two separate proposals? b) tweak worker MPM to automatically bump the value of MaxSpareThreads to at least 15% of MaxClients, with a warning written to the error log I like this best, because is requires no action on the user's part to take advantage of the change. Just so I understand the problem correctly, you're saying that when Worker is trying hard to stay near that MaxSpareThreads setting, and under a condition that pushes the server constantly up near that threshold (eg. when you have a sustained connection rate that is higher than MaxSpareThreads) then the turnover of connections causes Worker to kill and respawn children quickly, but that since the turnover is so quick you end up having children lingering around with one or two thread slots and essentially we approach the prefork scenario in terms of number of child processes. Is this correct? -aaron
Re: Host and Type Container
Jim Jagielski wrote: Paul Querna wrote: I just was looking at the ap_get_server_name() function, and I didn't like how it behaves when UseConicalName is 'on'. It currently will return 'r-server-server_hostname'. This makes it hard for a dynamic vhosting module to set it per-request. If we copied the r-server-server_hostname into r-hostname when the request was created, then modules could easily override r-hostname. But that kind of defeats the whole concept of UCN On, doesn't it? Or at least blurs the meaning... Perhaps just move the UCN on check to when we create the request_rec... Then anyone could change it later, if they thought they knew better.
Re: Puzzling News
On Feb 28, 2005, at 1:17 PM, Paul A. Houle wrote: Honestly, I don't see a huge advantage in going to worker. On Linux performance is about the same as prefork, although I haven't done benchmarking on Solaris. Under low-load conditions prefork often out-performs worker. Under high-concurrency scenarios, worker tends to degrade gracefully while under prefork you run the risk of running out of memory. Another benefit of worker that I've seen is that it can respond to requests with lower latency, which may have a positive impact on a user's experience (pages snap in more quickly). It would be nice to get some updated benchmarks on the relative metrics, like requests/second, concurrency, latency, etc... -aaron
Re: worker MPM: it sucks to have minimal MaxSpareThreads
On Mon, 7 Mar 2005 08:35:12 -0800, Aaron Bannert [EMAIL PROTECTED] wrote: On Mar 4, 2005, at 12:08 PM, Jeff Trawick wrote: Any comments on these two separate proposals? b) tweak worker MPM to automatically bump the value of MaxSpareThreads to at least 15% of MaxClients, with a warning written to the error log I like this best, because is requires no action on the user's part to take advantage of the change. same here Just so I understand the problem correctly, you're saying that when Worker is trying hard to stay near that MaxSpareThreads setting, and under a condition that pushes the server constantly up near that threshold (eg. when you have a sustained connection rate that is higher than MaxSpareThreads) then the turnover of connections causes Worker to kill and respawn children quickly, but that since the turnover is so quick you end up having children lingering around with one or two thread slots and essentially we approach the prefork scenario in terms of number of child processes. Is this correct? yes, that is correct... the more lengthy the response time, the worse the problem gets Thanks for your comments.
Re: Host and Type Container
Paul Querna wrote: Hmm. Less sure about this one. It seems like it overlaps with other things like AddOutputFilterbyType, but, it might be a better way to handle it anyways: Type application/xml AddOutputFilter XSLT;DEFLATE TransformOptions +ApacheFS /Type I have cases where I need to apply some directive to all text files. Currently I have to do it this way: FilesMatch \.(htm|html|txt|) Blah On /FilesMatch and it would be easier to do this: TypeMatch text/(html|plain) Blah On /TypesMatch It seems trivial, but I do have some more complicated cases that I currently have to hack up my modules to do this. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: [VOTE] 2.1.3 as beta
Paul Querna wrote: I think it should be hacked into mod_authnz_ldap, and if it works, then work can be done to generalize it to all the authnz modules. Right now we really don't know what is required to get it done. It is all just mailing list talk and theory. The trouble is that any work hacking it into mod_authnz_ldap isn't the kind of work that can be extended to other modules, it will simply be a hack into mod_authnz_ldap. Yes, we can then extend the same hack into the other modules, but then we're just duplicating functionality across modules that should be common. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Multiple AAA providers
At 10:11 AM 3/7/2005, Brad Nicholes wrote: I believe that we are talking about coding at the provider layer (ldap, file, etc.). Absolutely not my intention. Again, I do not want to have each provider have to reimplement the same code and parsing. I want a single module to do so, and the providers to be oblivious (but still work.) [ ] Implement across providers Single AuthProviderAlias real-provider-name alias directive. If they are saying the same thing then we might all be on the same page. Now would be a great time to have one of those white board discussions like we have at ApacheCon :). Agreed :) I would like to see us implement a syntax that can be reused as I suggested earlier. An AuthProviderAlias ... tag would allow for that. I am -1 to Bill's original proposal mainly because each use of an auth module requires that it be reconfigured within it's Location even if the configurations across Locations are identical. That's not accurate. It's allowed, but remember inheritance applies, In the module I already hacked, it's possible to VirtualHost xxx AuthConfig AuthDirectives /AuthConfig and that will also be inherited. But I didn't propose named aliases, which could be a very cool idea. If Bill's original proposal was reworked to pull the AuthConfig out of the Location scope and allow it to be reused as an alias, then I am +1. I'd be even more partial to allowing them in location scope, with alias names, and merging up the aliases. My concern is names clashing, on servers with massive VHOST lists. Allowing you to 'refine' a given alias... e.g. AuthConfig alt-ldap AuthLdapDirectives /AuthConfig VirtualHost xxx Location /private AuthConfig alt-ldap AuthLdap additional or overridden directives /AuthConfig ... then I think your preference for named sections, and my preference for scoped sections could both be satisfied. I'll give some thought to binding AuthConfig to a specific provider 'alias', v.s. allowing more complex control.
Re: [VOTE] 2.1.3 as beta
At 10:21 AM 3/7/2005, Paul Querna wrote: I disagree. The current authentication in 2.1 is far far better than what 2.0 has. I have been using it in production variations for over 2 years now. Just the ability to use any authentication backend with Digest is a huge improvement. ++1 - and I've always agreed. My only question is does the new API make it impossible to do simple things. I believe the best method is to attack it at the point of least work, and if it ends up being good, look at extending it to everything. I think it should be hacked into mod_authnz_ldap, and if it works, then work can be done to generalize it to all the authnz modules. Right now we really don't know what is required to get it done. It is all just mailing list talk and theory. Ok, I'd seriously disagree :) mod_authnz_ldap is already difficult enough to follow, keeping it as fundamental as it is today, and extending this externally, ensures we don't add bugs to _ldap just as we want to release a beta. I do not believe it is appropriate to threaten a -1 veto on 2.2.0 for this issue. Whoops - I never said veto to 2.2 (I don't think) ... you can't veto a beta. You vote, and it's majority rule on releases (and always has been.) Minimum 3 +1's, more +1's than -1's. Its not a regression, its not something we have a patch for, its something that didn't exist a week ago. If the new API makes things more difficult, it's a regression. This AAA provider discussion just offers us the opportunity to really evaluate the usefulness of the new API, are things going to be better or worse when you want to do something beyond add a single-use provider. And maybe the API doesn't interfere in which case we prove that the new API doesn't hinder development, but promotes it. We already know the new API makes it simpler to implement SQL, ODBC or other back ends folks care to create or port to 2.2 Bill
Re: Multiple AAA providers
I believe that we are talking about coding at the provider layer (ldap, file, etc.). Absolutely not my intention. Again, I do not want to have each provider have to reimplement the same code and parsing. I want a single module to do so, and the providers to be oblivious (but still work.) Let me clarify, we are talking about coding at the provider framework, not each provider itself. In other words, the authconfig module would do basically what you have proposed as far as merging config options outside of the actual provider module. The only difference would be allowing the authconfig configuration to be aliased so that it can be reused. I think we are close to the same page but I will wait to review the code that you come up with. Also the reason for the syntax authconfig ldap alt-ldap is so that the authconfig module knows what the base provider is. Otherwise how will it know which provider to call once the configuration merge is done? Then there would be no need for this syntax: VirtualHost xxx Location /private AuthConfig alt-ldap AuthLdap additional or overridden directives /AuthConfig It could be replaced with: VirtualHost xxx Location /private AuthProvider alt-ldap AuthLdap additional or overridden directives... Which more closely maps to the configuration syntax today. Brad William A. Rowe, Jr. [EMAIL PROTECTED] Monday, March 07, 2005 4:47:15 PM At 10:11 AM 3/7/2005, Brad Nicholes wrote: I believe that we are talking about coding at the provider layer (ldap, file, etc.). Absolutely not my intention. Again, I do not want to have each provider have to reimplement the same code and parsing. I want a single module to do so, and the providers to be oblivious (but still work.) [ ] Implement across providers Single AuthProviderAlias real-provider-name alias directive. If they are saying the same thing then we might all be on the same page. Now would be a great time to have one of those white board discussions like we have at ApacheCon :). Agreed :) I would like to see us implement a syntax that can be reused as I suggested earlier. An AuthProviderAlias ... tag would allow for that. I am -1 to Bill's original proposal mainly because each use of an auth module requires that it be reconfigured within it's Location even if the configurations across Locations are identical. That's not accurate. It's allowed, but remember inheritance applies, In the module I already hacked, it's possible to VirtualHost xxx AuthConfig AuthDirectives /AuthConfig and that will also be inherited. But I didn't propose named aliases, which could be a very cool idea. If Bill's original proposal was reworked to pull the AuthConfig out of the Location scope and allow it to be reused as an alias, then I am +1. I'd be even more partial to allowing them in location scope, with alias names, and merging up the aliases. My concern is names clashing, on servers with massive VHOST lists. Allowing you to 'refine' a given alias... e.g. AuthConfig alt-ldap AuthLdapDirectives /AuthConfig VirtualHost xxx Location /private AuthConfig alt-ldap AuthLdap additional or overridden directives /AuthConfig ... then I think your preference for named sections, and my preference for scoped sections could both be satisfied. I'll give some thought to binding AuthConfig to a specific provider 'alias', v.s. allowing more complex control.
Re: Multiple AAA providers
--On Monday, March 7, 2005 5:47 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Absolutely not my intention. Again, I do not want to have each provider have to reimplement the same code and parsing. I want a single module to do so, and the providers to be oblivious (but still work.) Brad's suggestion satisfies those exact requirements while being at the provider layer - which is infinitely more efficient than the AuthConfig that has been proposed. Again, what is specifically unsatisfactory with the idea? -- justin
Re: [VOTE] 2.1.3 as beta
--On Monday, March 7, 2005 5:37 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: ++1 - and I've always agreed. My only question is does the new API make it impossible to do simple things. ... If the new API makes things more difficult, it's a regression. This AAA provider discussion just offers us the opportunity to really evaluate the usefulness of the new API, are things going to be better or worse when you want to do something beyond add a single-use provider. And maybe the API doesn't interfere in which case we prove that the new API doesn't hinder development, but promotes it. We already know the new API makes it simpler to implement SQL, ODBC or other back ends folks care to create or port to 2.2 Considering that the AAA rewrite we have today does not change *any* existing AAA APIs that were in 2.0, but only adds APIs - I find it extremely hard to believe that 2.1 can not do things that 2.0 could. -- justin
request_rec, no_cache
Hi, There is a no_cache field in the request rec. It only seems to be set by mod_negotiation. Given the big chunk of comments at mod_negotiation.c:2920 I'm not sure if we actually need this field, or if we can reach the same result in another fashion (without some dodgy flag). Thoughts? Sander
Re: [VOTE] 2.1.3 as beta
Jim Jagielski wrote: I vote +1 for a beta. Ditto. Sander
[PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Hi,
Currently CacheIgnoreCacheControl On only ignores Cache-Control: no-cache
and Pragma: no-cache. I'd like to add ignoring Cache-Control: max-age=...
and Cache-Control: min-fresh=... as well.
This would give the admin more control, and would also make the directive
slightly more intuitive IMO. This because different browsers do different
things. One will send a Cache-Control: no-cache on a refresh, and one will
send a Cache-Control: max-age=... It would be nice if the effect would
be the same for both.
Thoughts?
Sander
Log:
Make CacheIgnoreCacheControl do what it implies, at least when it comes to
freshness checks.
* modules/cache/cache_util.c
(ap_cache_check_freshness): Ignore CacheControl: max-age and min-fresh
as well if CacheIgnoreCacheControl is set.
Index: modules/cache/cache_util.c
===
--- modules/cache/cache_util.c (revision 156480)
+++ modules/cache/cache_util.c (working copy)
@@ -122,6 +122,9 @@
char *val;
apr_time_t age_c = 0;
cache_info *info = (h-cache_obj-info);
+cache_server_conf *conf =
+ (cache_server_conf *)ap_get_module_config(r-server-module_config,
+cache_module);
/*
* We now want to check if our cached data is still fresh. This depends
@@ -162,9 +165,6 @@
if (ap_cache_liststr(NULL, pragma, no-cache, NULL)
|| ap_cache_liststr(NULL, cc_req, no-cache, NULL)) {
-cache_server_conf *conf =
- (cache_server_conf *)ap_get_module_config(r-server-module_config,
-cache_module);
if (!conf-ignorecachecontrol) {
/* Treat as stale, causing revalidation */
@@ -172,7 +172,7 @@
}
ap_log_error(APLOG_MARK, APLOG_INFO, 0, r-server,
- Incoming request may be asking for a uncached version of
+ Incoming request is asking for a uncached version of
%s, but we know better and are ignoring it,
r-unparsed_uri);
}
@@ -197,7 +197,8 @@
}
/* extract max-age from request */
-if (cc_req ap_cache_liststr(r-pool, cc_req, max-age, val)) {
+if (!conf-ignorecachecontrol
+ cc_req ap_cache_liststr(r-pool, cc_req, max-age, val)) {
maxage_req = apr_atoi64(val);
}
else {
@@ -234,7 +235,8 @@
}
/* extract min-fresh */
-if (cc_req ap_cache_liststr(r-pool, cc_req, min-fresh, val)) {
+if (!conf-ignorecachecontrol
+ cc_req ap_cache_liststr(r-pool, cc_req, min-fresh, val)) {
minfresh = apr_atoi64(val);
}
else {
Re: [VOTE] 2.1.3 as beta
jakarta-tomcat-dev reports Gump can't build, but since they haven't given us details so not much we can do about it. Fails to even build on Win32. -1 for beta on 2.1.3. Onward to 14 ++1 to Sander's efforts to roll out 2.1.4 ... let's get it right (at least, let's have something that builds, irrespective of it has the features folks want.) I've chided tomcat-dev to bother to report to us what their Gump results are. Would go a long ways to solving a problem we didn't know exists. Bill At 08:51 PM 3/7/2005, Sander Striker wrote: Jim Jagielski wrote: I vote +1 for a beta. Ditto. Sander
Re: [VOTE] 2.1.3 as beta
William A. Rowe, Jr. wrote: jakarta-tomcat-dev reports Gump can't build, but since they haven't given us details so not much we can do about it. Fails to even build on Win32. -1 for beta on 2.1.3. I think we passed the 2.1.3 station already. Onward to 14 ++1 to Sander's efforts to roll out 2.1.4 ... let's get it right (at least, let's have something that builds, irrespective of it has the features folks want.) So what is failing to build? 2.1.3? Or trunk? Only on win32, or on other platforms as well? Can you reproduce? I've chided tomcat-dev to bother to report to us what their Gump results are. Would go a long ways to solving a problem we didn't know exists. It seems to build fine in the ASF wide Gump run on brutus: http://brutus.apache.org/gump/public/apache-httpd/index.html Sander
