DO NOT REPLY [Bug 33900] New: - Multiple Cookies cannot be set from ASP.NET application
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=33900. 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=33900 Summary: Multiple Cookies cannot be set from ASP.NET application Product: Apache mod_aspdotnet Version: 2.0.0 Platform: PC URL: http://polidea.pl OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Apache.Web AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Multiple Cookies cannot be set from ASP.NET application because they are replaced by function apr_table_setn. Fix: WorkerRequest.h, Line 542 virtual void SendKnownResponseHeader(int index, String* value) if (index == HeaderContentType) ap_set_content_type(rr, poolval); else if(index == HeaderSetCookie) apr_table_addn(rr-headers_out, response_headers_name_c[index], poolval); else apr_table_setn(rr-headers_out, response_headers_name_c[index], poolval); -- 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.
Caching a value for the lifetime of a module: CLUELESS
My understanding about per server conf is that any structure allocated
in the server config handler should have a lifetime that is the same
as the one of the module. So the server config structure should be an
ideal place for caching values. Anyway in the following simple module
the dbg counter is correctly incremented only for requests made within
the same connection. When i close the brower, reopen it and make
another request, dbg is set to 0. I am clueless and don't understand
what is wrong with this code.
Thanks in advance for your attention,
Luca
typedef struct
{
//apr_hash_t *url_ht;
#ifdef DBG_print_cache
int dbg;
#endif
} server_config;
/* Declare the module name */
module AP_MODULE_DECLARE_DATA sds_debug_module;
static void log(char * log)
{
fprintf(stderr,log);
fflush(stderr);
}
static void *create_server_config(apr_pool_t *p,server_rec *s)
{
server_config *sconf = apr_palloc(p,sizeof(*sconf));
//sconf-url_ht= apr_hash_make(p);
#ifdef DBG_create_server_config
fprintf(stderr,calling create_server_config \n);
fflush(stderr);
sconf-dbg=0;
#endif
return (void *) sconf;
}
static void print_cache(request_rec *r)
{
#ifdef DBG_print_cache
server_config *conf;
conf=(server_config*)
ap_get_module_config(r-server-module_config,sds_debug_module);
fprintf(stderr,DBG: %d\n,conf-dbg);
fflush(stderr);
conf-dbg++;
#endif
}
static int cache_url_handler(request_rec *r, int lookup)
{
print_cache(r);
return DECLINED;
}
/* Register the filter function as a filter for modifying the HTTP
body (content) */
static void register_hooks(apr_pool_t *p)
{
// cache initializer
// cache handler
ap_hook_quick_handler(cache_url_handler, NULL, NULL, APR_HOOK_FIRST);
// cache filters
// XXX The cache filters need to run right after the handlers and before
// any other filters. Consider creating AP_FTYPE_CACHE for this purpose.
// Make them AP_FTYPE_CONTENT for now.
// XXX ianhH:they should run AFTER all the other content filters.
//
}
/* Define the module data */
module AP_MODULE_DECLARE_DATA sds_debug_module =
{
STANDARD20_MODULE_STUFF,
NULL,/* dir config creater */
NULL,/* dir merger --- default is to override */
create_server_config,/* server config */
NULL,/* merge server config */
NULL,/* command apr_table_t */
register_hooks /* register hook */
};
Mod_MEM_cache doesn't use Pools to allocate cache objects???
Taking a look at mod_mem_cache source code i have seen that it doesn't use pools to allocate cache objects but i does so by means of reference counting and simple calloc/free calls. I have also seen that this module requires a Threaded apr to work. I am wondering the reasons of this design choices. I am developing a web service caching module and now i have some issues with caching some web service parameters correctly. I store these parameters in a per server config object but it seems that stored data is valid only on a per connection base. My developement version of Apache 2.0 is compiled in maintainer mode with a prefork mpm. I would like to contribute the module to the apache group if i manage to develop something usable. Thanks in advance. Luca
Re: Mod_MEM_cache doesn't use Pools to allocate cache objects???
luca regini wrote: Taking a look at mod_mem_cache source code i have seen that it doesn't use pools to allocate cache objects but i does so by means of reference counting and simple calloc/free calls. I have also seen that this module requires a Threaded apr to work. I am wondering the reasons of this design choices. If you allocate the cache objects out of a pool, what happens to the memory when stale objects are garbage collected?
Proposed LDAP Fix
Title: Message
I had problems with
LDAP modules in 2.0.53 on Windows. It authenticates fine, but when I shut
down apache I get those Microsoft alerts saying something went wrong. It
only happens when I have the ldap modules enabled.The problem is in
modules/experimental/util_ldap_cache.c in the util_ldap_cache_module_kill()
method. The cache_file is null. Adding a null check prior to calling
apr_file_remove() fixed the issue. Any thoughts?
Thanks.
,
Josh.
apr_status_t
util_ldap_cache_module_kill(void *data){
util_ldap_state_t *st = (util_ldap_state_t *)data;
util_ald_destroy_cache(st-util_ldap_cache);#if
APR_HAS_SHARED_MEMORY if (st-cache_rmm != NULL)
{ apr_rmm_destroy
(st-cache_rmm);
st-cache_rmm = NULL; } if
(st-cache_shm != NULL) {
apr_status_t result =
apr_shm_destroy(st-cache_shm);
st-cache_shm = NULL;if ( st-cache_file != NULL )
//ADDED THIS LINEapr_file_remove(st-cache_file,
st-pool); return
result; }#endif return
APR_SUCCESS;}
Re: Mod_MEM_cache doesn't use Pools to allocate cache objects???
On Tue, 8 Mar 2005, Bill Stoddard wrote: luca regini wrote: Taking a look at mod_mem_cache source code i have seen that it doesn't use pools to allocate cache objects but i does so by means of reference counting and simple calloc/free calls. I have also seen that this module requires a Threaded apr to work. I am wondering the reasons of this design choices. If you allocate the cache objects out of a pool, what happens to the memory when stale objects are garbage collected? Bad Things(tm). :) However, it should be possible to use a custom apr_allocator_t instead of directly calling calloc/free. Might be a little faster?
Re: Caching a value for the lifetime of a module: CLUELESS
That's exactly what happens and i learnt it the hard way :). Now my next question is: is there any ideal place provided by the apache API to allocate a shared memory object? Is there any source code example of such a use case? Thanks. Luca On Tue, 8 Mar 2005 10:11:57 -0500 (EST), Cliff Woolley [EMAIL PROTECTED] wrote: On Tue, 8 Mar 2005, luca regini wrote: My understanding about per server conf is that any structure allocated in the server config handler should have a lifetime that is the same as the one of the module. So the server config structure should be an ideal place for caching values. But actually, it's not an ideal place at all, for the very reason you're finding here. I suspect what's happening to your code is that you're running up against the fact that each child process has its own copy of the server_rec and all of the server_config structures. They are not in shared memory, they're just duplicated when the parent forks itself. Therefore these structures are really only meant to be written to by the parent at config time. Writing to them after that point will result in inconsistent state across children. --Cliff
Re: Mod_MEM_cache doesn't use Pools to allocate cache objects???
luca regini wrote: Taking a look at mod_mem_cache source code i have seen that it doesn't use pools to allocate cache objects but i does so by means of reference counting and simple calloc/free calls. I have also seen that this module requires a Threaded apr to work. If you use prefork, each child is a fork and has it's own memory space, so you are unable to share data between child - bad idea The way you can do is code a cache module using shared memory but in this case, shm and rmm are not using pools, and i think there will be performances issues. It depend on what you want to do with your cache module. Actually, in a threaded mpm, each child and the threads inside are sharing common data. So you have duplicated cache data in each forked child. The performance depend on how you setup your server. low child number and high thread number = few request on backend and only few duplicated data. Coding a cache module using shared memory is huge work. Good luck if you choose to do it Matthieu
Re: worker MPM: it sucks to have minimal MaxSpareThreads
Aaron Bannert wrote: Just so I understand the problem correctly, 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? in worker + event there is also the squatting logic where newly spawned children take over partially empty scoreboard slots in a non-intuitive manner. so excessive killing spawning can lead into strange code paths and Bad Things that can't happen in prefork. Greg
Re: [VOTE] 2.1.3 as beta
On Tue, Mar 08, 2005 at 08:49:52AM +0100, Sander Striker wrote: So what is failing to build? 2.1.3? Or trunk? Only on win32, or on other platforms as well? Can you reproduce? Note that 2.1.3 fails to build on Win32 because APR 1.1.0 doesn't build. This Win32 failure is *not* an httpd problem. Mladen reported that using APR trunk worked fine with 2.1.3. The Win32-savvy APR developers need to figure out what's wrong and help us backport the changes to APR 1.1.x and help us release 1.1.1. (IMHO, with my APR hat on, releasing 1.2.0 is not an option for APR as apr_dbd isn't ready.) I and others have repeatedly said that we refuse to tie *any* httpd release to a non-released version of APR. And, I don't like to see httpd -1ed because APR screwed something up. -- justin
Re: [apache-modules] Caching a value for the lifetime of a module: CLUELESS
Which operating system you are using? If you are using unix os, this problem
may be due to the prefork process which will be created to serve for
each connection. In that case you may have to use shared memory...
Regards,
Asok
My understanding about per server conf is that any structure allocated
in the server config handler should have a lifetime that is the same
as the one of the module. So the server config structure should be an
ideal place for caching values. Anyway in the following simple module
the dbg counter is correctly incremented only for requests made within
the same connection. When i close the brower, reopen it and make
another request, dbg is set to 0. I am clueless and don't understand
what is wrong with this code.
Thanks in advance for your attention,
Luca
typedef struct
{
//apr_hash_t *url_ht;
#ifdef DBG_print_cache
int dbg;
#endif
} server_config;
/* Declare the module name */
module AP_MODULE_DECLARE_DATA sds_debug_module;
static void log(char * log)
{
fprintf(stderr,log);
fflush(stderr);
}
static void *create_server_config(apr_pool_t *p,server_rec *s)
{
server_config *sconf = apr_palloc(p,sizeof(*sconf));
//sconf-url_ht= apr_hash_make(p);
#ifdef DBG_create_server_config
fprintf(stderr,calling create_server_config \n);
fflush(stderr);
sconf-dbg=0;
#endif
return (void *) sconf;
}
static void print_cache(request_rec *r)
{
#ifdef DBG_print_cache
server_config *conf;
conf=(server_config*)
ap_get_module_config(r-server-module_config,sds_debug_module);
fprintf(stderr,DBG: %d\n,conf-dbg);
fflush(stderr);
conf-dbg++;
#endif
}
static int cache_url_handler(request_rec *r, int lookup)
{
print_cache(r);
return DECLINED;
}
/* Register the filter function as a filter for modifying the HTTP
body (content) */
static void register_hooks(apr_pool_t *p)
{
// cache initializer
// cache handler
ap_hook_quick_handler(cache_url_handler, NULL, NULL, APR_HOOK_FIRST);
// cache filters
// XXX The cache filters need to run right after the handlers and before
// any other filters. Consider creating AP_FTYPE_CACHE for this purpose.
// Make them AP_FTYPE_CONTENT for now.
// XXX ianhH:they should run AFTER all the other content filters.
//
}
/* Define the module data */
module AP_MODULE_DECLARE_DATA sds_debug_module =
{
STANDARD20_MODULE_STUFF,
NULL,/* dir config creater */
NULL,/* dir merger --- default is to override */
create_server_config,/* server config */
NULL,/* merge server config */
NULL,/* command apr_table_t */
register_hooks /* register hook */
};
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: piped log bug?
So is there any progress with the issue or just nobody is interested? arkadi. On my medium busy FreeBSD and Linux servers I noticed that sometimes apache leaves previous instance children in non-working state after restart. Examination with ps/strace/truss shows that all of them are writing to piped (cronolog backed) access log, but by that time all cronolog processes are already gone.
Re: piped log bug?
On 8 Mar 2005, at 17:00, Arkadi Shishlov wrote: So is there any progress with the issue or just nobody is interested? I don't have the original post but I may have an alternative to piped logs if this is a problem for anyone. Sorry for the plug, especially if it's a bit off-topic but http://hexten.net/sw/mod_log_rotate/index.mhtml does in-process log rotation. -- Andy Armstrong, hexten.net
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Justin Erenkrantz wrote: On Tue, Mar 08, 2005 at 03:57:55AM +0100, Sander Striker wrote: 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? While I think this is a good idea, I'd like to consider renaming this particular directive as I think the name is really confusing. Does that mean you want me to hold off on committing this patch pending a directive rename? Isn't that a seperate issue? My concern is that CacheIgnoreCacheControl only refers to the request's Cache-Control not the origin response's Cache-Control header. But, I like that separation because having it refer to both is too coarse-grained, I think. Definately agreed. Ignoring response Cache-Control is in another league than ignoring the request Cache-Control. But, I don't have any real ideas for what an alternative name is. -- justin CacheIgnoreServerCacheControl? Sander
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
On Tue, Mar 08, 2005 at 06:01:35PM +0100, Sander Striker wrote: While I think this is a good idea, I'd like to consider renaming this particular directive as I think the name is really confusing. Does that mean you want me to hold off on committing this patch pending a directive rename? Isn't that a seperate issue? Nah, go ahead and commit if you like. It's just that you brought up the point of making the directive more intuitive - and I have problems from the word go on this particular directive being intuitive. It's not. In order to understand what this directive does, you need to know what Cache-Control from the RFC means - and that's not intuitive. I'd like something that expresses the concept that we will serve cached content even if the client asks for 'fresh' content. The closest I can come up with is 'CacheServeStale' - but that's not quite right or even precise either. My concern is that CacheIgnoreCacheControl only refers to the request's Cache-Control not the origin response's Cache-Control header. But, I like that separation because having it refer to both is too coarse-grained, I think. Definately agreed. Ignoring response Cache-Control is in another league than ignoring the request Cache-Control. Correct. But, I don't have any real ideas for what an alternative name is. -- justin CacheIgnoreServerCacheControl? Per above, I don't like the phrase Cache-Control. -- justin
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Justin Erenkrantz wrote: On Tue, Mar 08, 2005 at 06:01:35PM +0100, Sander Striker wrote: While I think this is a good idea, I'd like to consider renaming this particular directive as I think the name is really confusing. Does that mean you want me to hold off on committing this patch pending a directive rename? Isn't that a seperate issue? Nah, go ahead and commit if you like. It's just that you brought up the point of making the directive more intuitive - and I have problems from the word go on this particular directive being intuitive. It's not. In order to understand what this directive does, you need to know what Cache-Control from the RFC means - and that's not intuitive. I'd like something that expresses the concept that we will serve cached content even if the client asks for 'fresh' content. The closest I can come up with is 'CacheServeStale' - but that's not quite right or even precise either. CacheForOffline? (or Cache4Offline) Offline browsing is the main case where you need such absolute caching. But it requires you to cache EVERYTHING. Including dynamic content, and even different content according to different POST input. Maybe two directives are needed, one for using the cache only if the cookies are the same. All of that requires changing the caching mechanism to keep POST input, cookies, etc. I started to do it in the past, and planned to contribute it when it would be ready, but held on when the major modifications of mod_cache started. I think that Brian Akins made a similar patch too, and wanted to contribute it, but failed to pass CNN's lawyers. If I recall correctly, he volunteered to give tips. -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Justin Erenkrantz wrote: It's just that you brought up the point of making the directive more intuitive - and I have problems from the word go on this particular directive being intuitive. It's not. In order to understand what this directive does, you need to know what Cache-Control from the RFC means - and that's not intuitive. I'd like something that expresses the concept that we will serve cached content even if the client asks for 'fresh' content. Agreed. The closest I can come up with is 'CacheServeStale' - but that's not quite right or even precise either. Cache-Control is per definition a bit of a tough thing to translate to a term like Stale or Fresh, since it can require both. [...] Per above, I don't like the phrase Cache-Control. -- justin Fair enough. What about: CacheIgnoreClientAgeRequirements ? A bit long maybe. Sigh. I'm not very good at coming up with short yet descriptive directive names I'm afraid. Sander
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Eli Marmor wrote: [...] CacheForOffline? (or Cache4Offline) Offline browsing is the main case where you need such absolute caching. But it requires you to cache EVERYTHING. Including dynamic content, and even different content according to different POST input. Maybe two directives are needed, one for using the cache only if the cookies are the same. All of that requires changing the caching mechanism to keep POST input, cookies, etc. I think you just proved Justins point. Above is all about response Cache-Control. The current CacheIgnoreCacheControl only affects request Cache-Control. Confuzzled yet ;) :) Sander
Re: piped log bug?
On Tue, 08 Mar 2005 19:00:05 +0200, Arkadi Shishlov [EMAIL PROTECTED] wrote: So is there any progress with the issue or just nobody is interested? me interested? yes me have time right now? no The more investigation work you can do, the better.
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Sander Striker wrote: Eli Marmor wrote: [...] CacheForOffline? (or Cache4Offline) Offline browsing is the main case where you need such absolute caching. But it requires you to cache EVERYTHING. Including dynamic content, and even different content according to different POST input. Maybe two directives are needed, one for using the cache only if the cookies are the same. All of that requires changing the caching mechanism to keep POST input, cookies, etc. I think you just proved Justins point. Above is all about response Cache-Control. The current CacheIgnoreCacheControl only affects request Cache-Control. Confuzzled yet ;) :) Sander If I recall correctly, there were MANY conditions in mod_cache that prevented caching (like checking for a POST method, no-store, no-cache, auth, GET args, private, public, must-revalidate, maxage, etc.). My idea was to have one directive, with an option for each of them, including the conditions that are already supported, plus two special options - one that represents the empty set of options, and one that turns on all of the options. -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
--On Tuesday, March 8, 2005 8:12 PM +0200 Eli Marmor [EMAIL PROTECTED] wrote: If I recall correctly, there were MANY conditions in mod_cache that prevented caching (like checking for a POST method, no-store, no-cache, auth, GET args, private, public, must-revalidate, maxage, etc.). My idea was to have one directive, with an option for each of them, including the conditions that are already supported, plus two special options - one that represents the empty set of options, and one that turns on all of the options. Hmm. That's an interesting approach. How about an ITERATE directive with a bit-wise field that represent their value in the config structure? I sort of like that... =) To be clear, something like: CacheOptions +StorePrivate +IgnoreClientControl +IgnoreServerControl +CachePOST +CacheAuth CacheOptions +all CacheOptions -all Feel like writing a patch? =) -- justin
Re: piped log bug?
On Tue, Mar 08, 2005 at 01:22:46PM -0500, Jeff Trawick wrote: On Tue, 08 Mar 2005 19:00:05 +0200, Arkadi Shishlov [EMAIL PROTECTED] wrote: So is there any progress with the issue or just nobody is interested? me interested? yes me have time right now? no The more investigation work you can do, the better. If you agree with the 'diagnosis' I can try to cook two patches to verify it. 1. Do not kill pipe log process, let it read the pipe till EOF. Or a patch to cronolog to ignore SIGTERM. 2. Close pipe rd side in children. Is it possible to do in clean way via apr*register/whatever? arkadi.
Re: worker MPM: it sucks to have minimal MaxSpareThreads
Jeff Trawick wrote: Then realize you need to support boatloads more clients, so you bump up MaxClients to 5000. Now when load changes very slightly (as a percentage of MaxClients), which happens continuously, the web server will create or destroy a child process. 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 +1 to b), btw. we've had offline discussions about optimizing MaxSpareThreads according to the variance seen in busy threads, but that's for admins who know what they're doing. 15% is pretty conservative and should help sites with less experienced admins. Greg
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Justin Erenkrantz wrote: --On Tuesday, March 8, 2005 8:12 PM +0200 Eli Marmor [EMAIL PROTECTED] wrote: If I recall correctly, there were MANY conditions in mod_cache that prevented caching (like checking for a POST method, no-store, no-cache, auth, GET args, private, public, must-revalidate, maxage, etc.). My idea was to have one directive, with an option for each of them, including the conditions that are already supported, plus two special options - one that represents the empty set of options, and one that turns on all of the options. Hmm. That's an interesting approach. How about an ITERATE directive with a bit-wise field that represent their value in the config structure? I sort of like that... =) To be clear, something like: CacheOptions +StorePrivate +IgnoreClientControl +IgnoreServerControl +CachePOST +CacheAuth CacheOptions +all CacheOptions -all Feel like writing a patch? =) -- justin Exactly. This is what I started to code (using an ancient release...). I stole some code from Options. -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: worker MPM: it sucks to have minimal MaxSpareThreads
Greg Ames wrote: Jeff Trawick wrote: Then realize you need to support boatloads more clients, so you bump up MaxClients to 5000. Now when load changes very slightly (as a percentage of MaxClients), which happens continuously, the web server will create or destroy a child process. 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 +1 to b), btw. we've had offline discussions about optimizing MaxSpareThreads according to the variance seen in busy threads, but that's for admins who know what they're doing. 15% is pretty conservative and should help sites with less experienced admins. Greg +1 Bill
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Eli Marmor wrote: Justin Erenkrantz wrote: --On Tuesday, March 8, 2005 8:12 PM +0200 Eli Marmor [EMAIL PROTECTED] wrote: If I recall correctly, there were MANY conditions in mod_cache that prevented caching (like checking for a POST method, no-store, no-cache, auth, GET args, private, public, must-revalidate, maxage, etc.). My idea was to have one directive, with an option for each of them, including the conditions that are already supported, plus two special options - one that represents the empty set of options, and one that turns on all of the options. Hmm. That's an interesting approach. How about an ITERATE directive with a bit-wise field that represent their value in the config structure? I sort of like that... =) To be clear, something like: CacheOptions +StorePrivate +IgnoreClientControl +IgnoreServerControl +CachePOST +CacheAuth CacheOptions +all CacheOptions -all Feel like writing a patch? =) -- justin Exactly. This is what I started to code (using an ancient release...). I stole some code from Options. I.e. from set_options() of server/core.c -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Justin Erenkrantz wrote: CacheOptions +StorePrivate +IgnoreClientControl +IgnoreServerControl +CachePOST +CacheAuth CacheOptions +all CacheOptions -all I suggest avoiding the +/- syntax which has proven confusing to many users and adds very little in functionality. Just use CacheOptions StorePrivate IgnoreClientControl IgnoreServerControl CachePOST CacheAuth CacheOptions All CacheOptions None Use AllowOverride as your example rather than Options. Joshua.
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Joshua Slive wrote: Justin Erenkrantz wrote: CacheOptions +StorePrivate +IgnoreClientControl +IgnoreServerControl +CachePOST +CacheAuth CacheOptions +all CacheOptions -all I suggest avoiding the +/- syntax which has proven confusing to many users and adds very little in functionality. Just use CacheOptions StorePrivate IgnoreClientControl IgnoreServerControl CachePOST CacheAuth CacheOptions All CacheOptions None Use AllowOverride as your example rather than Options. It depends if you need it only for the server configuration, or for dir_config; In the latter case, you don't have another choice, you just NEED the +- -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: piped log bug?
On Tue, Mar 08, 2005 at 09:01:20PM +0200, Arkadi Shishlov wrote: On Tue, Mar 08, 2005 at 01:22:46PM -0500, Jeff Trawick wrote: On Tue, 08 Mar 2005 19:00:05 +0200, Arkadi Shishlov [EMAIL PROTECTED] wrote: So is there any progress with the issue or just nobody is interested? me interested? yes me have time right now? no The more investigation work you can do, the better. If you agree with the 'diagnosis' I can try to cook two patches to verify it. The bug being discussed here is the same as this PR, right? http://issues.apache.org/bugzilla/show_bug.cgi?id=26467 1. Do not kill pipe log process, let it read the pipe till EOF. Or a patch to cronolog to ignore SIGTERM. 2. Close pipe rd side in children. Is it possible to do in clean way via apr*register/whatever? Yes - a child_init hook should be the right place to do (2), I think. joe
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
--On Tuesday, March 8, 2005 9:38 PM +0200 Eli Marmor [EMAIL PROTECTED] wrote: It depends if you need it only for the server configuration, or for dir_config; In the latter case, you don't have another choice, you just NEED the +- Actually, cache can't respect any dir config's (because it is a quick handler) so Joshua is right - we shouldn't follow the +-. -- justin
Re: piped log bug?
On Tue, Mar 08, 2005 at 08:11:10PM +, Joe Orton wrote: The bug being discussed here is the same as this PR, right? http://issues.apache.org/bugzilla/show_bug.cgi?id=26467 Yes. arkadi.
Re: [PATCH] mod_cache, expand impact of CacheIgnoreCacheControl
Justin Erenkrantz wrote: --On Tuesday, March 8, 2005 9:38 PM +0200 Eli Marmor [EMAIL PROTECTED] wrote: It depends if you need it only for the server configuration, or for dir_config; In the latter case, you don't have another choice, you just NEED the +- Actually, cache can't respect any dir config's (because it is a quick handler) so Joshua is right - we shouldn't follow the +-. -- justin I don't think it matters anyway. Note that AllowOverride handles dir configs. All the +/- syntax buys you is being able to write Directive Foo Bar Baz Directory /foo Directive -Bar +Boo /Directory Instead of Directive Foo Bar Baz Directory /foo Directive Foo Baz Boo /Directory Joshua.
Re: [VOTE] 2.1.3 as beta
At 01:49 AM 3/8/2005, Sander Striker wrote: William A. Rowe, Jr. wrote: 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? AFAIK win32 builds, I'll verify tonight. Have one odd emit about the pcre stuff, but it doesn't look to be a showstopper. Actually, one of my bigger beta concerns was picking up this update to pcre. Looks like now, we can. 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 Here is Bill Barker's report; http://issues.apache.org/bugzilla/show_bug.cgi?id=32787
Re: [VOTE] 2.1.3 as beta
At 10:22 AM 3/8/2005, Justin Erenkrantz wrote: Note that 2.1.3 fails to build on Win32 because APR 1.1.0 doesn't build. This Win32 failure is *not* an httpd problem. Mladen reported that using APR trunk worked fine with 2.1.3. Perhaps you aught to respond to the [EMAIL PROTECTED] post; Subject: 1.2? Fixes to libapr[util...].dll version resource Message Id: [EMAIL PROTECTED] rather than debate it here where it's off topic? Believe me, something I have already considered and am concerned about - and would like to see addressed (and help address).
Re: [Patch 30399] New directive CacheIgnoreHeaders to prevent user defined headers from being stored by mod_cache
[..cut..] Hi all, I recently noticed that we now have two votes (one from Justin and one from Bill, btw: thanks Bill) for backporting the patch for report 30399 to 2.0.x. As I and Dick Snippe (see http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=97403) would like to see this patch backported I am just asking if someone has some time (ok, wrong approach :-)) to have a look at the patch such that it can possibly receive a third +1. Maybe Nick who responded to Dicks posting or maybe the person who added a +0 for this patch to the status file? To ease the work of backporting I just attached a version of the patch against 2.0.53 to the report 30399. Thanks and regards Rüdiger
[PATCH] only allow mod_speling to correct capitalization
All,
We had a need here for mod_speling's case-correcting functionality but
we have generated filenames with very similar names so we were
constantly running afoul of its willingness to substitute the wrong
file when the correct one did not exist. I made a simple addition to
mod_speling to restrict it to case comparisons only, and added a
configuration flag CheckCaseOnly to enable or disable it. The default
behavior is as before.
Doc XML update is also included in the patch, against 2.0.53.
Sent here in the hopes that it might get picked up or at least be useful
to people who are in the same boat we are.
-m
diff -Naur httpd-2.0.53-orig/docs/manual/mod/mod_speling.xml
httpd-2.0.53/docs/manual/mod/mod_speling.xml
--- httpd-2.0.53-orig/docs/manual/mod/mod_speling.xml 2005-03-08
13:44:26.0 -0600
+++ httpd-2.0.53/docs/manual/mod/mod_speling.xml2005-03-08
13:45:46.0 -0600
@@ -25,7 +25,7 @@
namemod_speling/name
descriptionAttempts to correct mistaken URLs that
users might have entered by ignoring capitalization and by
-allowing up to one misspelling/description
+(potentially) allowing up to one misspelling/description
statusExtension/status
sourcefilemod_speling.c/sourcefile
identifierspeling_module/identifier
@@ -109,6 +109,31 @@
/ul
/usage
+nameCheckCaseOnly/name
+descriptionRestricts the spelling module to
+correcting miscapitalizations
+/description
+syntaxCheckCaseOnly on|off/syntax
+defaultCheckCaseOnly Off/default
+contextlist
+contextserver config/context
+contextvirtual host/context
+contextdirectory/context
+context.htaccess/context
+/contextlist
+overrideOptions/override
+usage
+
+p
+This option restricts the spelling corrections to changes
+in case. This is useful if you are moving from a case-insensitive
+system to a case-sensitive one and your users have become
+accustomed to using URLs in a case-insensitive manner, but you
+do not want to enable corrections for misspelled names.
+/p
+
+/usage
+
/directivesynopsis
/modulesynopsis
diff -Naur httpd-2.0.53-orig/modules/mappers/mod_speling.c
httpd-2.0.53/modules/mappers/mod_speling.c
--- httpd-2.0.53-orig/modules/mappers/mod_speling.c 2005-03-08
13:44:26.0 -0600
+++ httpd-2.0.53/modules/mappers/mod_speling.c 2005-03-08 13:45:11.0
-0600
@@ -49,6 +49,10 @@
* omitted.
* o wrote a kind of html page for mod_speling
*
+ * 07-Mar-2005 [EMAIL PROTECTED]
+ * o Added CheckCaseOnly option to only allow case fiddling and not
+ * the full range of spelling corrections.
+ *
* Activate it with CheckSpelling On
*/
@@ -56,6 +60,7 @@
typedef struct {
int enabled;
+int case_only;
} spconfig;
/*
@@ -72,6 +77,7 @@
spconfig *cfg = apr_pcalloc(p, sizeof(spconfig));
cfg-enabled = 0;
+cfg-case_only = 0;
return cfg;
}
@@ -104,6 +110,17 @@
}
/*
+ * Handler for the CheckCaseOnly directive, which is FLAG.
+ */
+static const char *set_case_only(cmd_parms *cmd, void *mconfig, int arg)
+{
+spconfig *cfg = (spconfig *) mconfig;
+
+cfg-case_only = arg;
+return NULL;
+}
+
+/*
* Define the directives specific to this module. This structure is referenced
* later by the 'module' structure.
*/
@@ -111,6 +128,8 @@
{
AP_INIT_FLAG(CheckSpelling, set_speling, NULL, OR_OPTIONS,
whether or not to fix miscapitalized/misspelled requests),
+AP_INIT_FLAG(CheckCaseOnly, set_case_only, NULL, OR_OPTIONS,
+ whether or not to correct only miscapitalizations),
{ NULL }
};
@@ -293,6 +312,12 @@
sp_new = (misspelled_file *) apr_array_push(candidates);
sp_new-name = apr_pstrdup(r-pool, dirent.name);
sp_new-quality = SP_MISCAPITALIZED;
+ /*
+* if we are just checking for miscapitalizations, then there's
+* no reason to continue on.
+*/
+ if (cfg-case_only)
+ continue;
}
/*
Bug handling Upgrade: TLS/1.0 header in ssl_engine_io.c
Hi httpd folks,
It seems that Joe Orton introduced a bug while updating ssl_engine_io.c
between version 109499 and version 59. The same bug was introduced
into NetWare's mod_nw_ssl.c version 111327. (Please forgive me if that's
not the correct way to reference svn version numbers... I'm new to svn.)
The code in question is part of the TLS Upgrade feature described in
RFC 2817 and was originally written by Ryan Bloom and committed by
Bill Rowe if I'm not mistaken.
Compare the new code:
upgrade = apr_table_get(r-headers_in, Upgrade);
if (upgrade == NULL
|| strcmp(ap_getword(r-pool, upgrade, ','), TLS/1.0)) {
/* Upgrade: TLS/1.0, ... header not found, don't do Upgrade */
return ap_pass_brigade(f-next, bb);
}
with the (bug-fixed, slightly cleaned-up) old code:
if (upgrade == NULL) {
/* Upgrade: header not found, don't do Upgrade */
return ap_pass_brigade(f-next, bb);
}
token_string = apr_pstrdup(r-pool,upgrade);
token = apr_strtok(token_string,, ,token_state);
while (token strcasecmp(token,TLS/1.0)) {
token = apr_strtok(NULL,, ,token_state);
}
if (token == NULL) {
/* TLS/1.0 token not in Upgrade header, * don't do Upgrade */
return ap_pass_brigade(f-next, bb);
}
While the new code is much shorter, it introduces a bug. Consider
the header Upgrade: SSL/3.0, TLS/1.0 or better yet, a derivation
of the example Upgrade header in the RFC 2616 snippet below with
TLS/1.0 somewhere besides the first spot. The new code fails the
upgrade on any Upgrade header whose first token is not TLS/1.0.
Also, I should mention that version 109499 had a bug where if
there was an Upgrade header that didn't have TLS/1.0 as the first
token, it got into an infinite loop. That's why I said bug-fixed
above.
Maybe someone who is more familiar with the apr_ and ap_ APIs can
generate some working code that is shorter and cleaner than the
strtok-based code above. Any correct implemenation I could think
of using ap_getword seemed like it would be messier than the
apr_strtok() version, especially since the tokens are in this case
each separated by one or more commas (,) and OPTIONAL linear
white space (LWS) (RFC 2616 2.1).
If there isn't an ap_ or apr_ function that seperates these tokens
more easily, I'm satisfied with the strtok based code above. Any
objections to me asking Brad Nicholes to commit it and revert that
part of 59? (The other changes in that commit were very good)
Thanks,
Joel
SNIP
Here's the applicable verbage from RFC 2817 for your convenience:
3. Client Requested Upgrade to HTTP over TLS
When the client sends an HTTP/1.1 request with an Upgrade header
field containing the token TLS/1.0, it is requesting the server to
complete the current HTTP/1.1 request after switching to TLS/1.0.
and from RFC 2616:
14.42 Upgrade
The Upgrade general-header allows the client to specify what
additional communication protocols it supports and would like to use
if the server finds it appropriate to switch protocols. The server
MUST use the Upgrade header field within a 101 (Switching Protocols)
response to indicate which protocol(s) are being switched.
Upgrade= Upgrade : 1#product
For example,
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
