Ipv6 tests with build 2.0.28.
Hi all,I have installed Apache beta version 2.0.28 on Linux machine and I am ableto ping6 with the ip address of the machineping6 -I eth0 fe80::260:67ff:fe36:4b0 is working.So i can say that my linux configuration is supporting IPv6.But when i tried to access default page of apache withhttp://[fe80::260:67ff:fe36:4b0] :80its giving no default page but if i try same with localhost i am gettingapache default page.is it necessary to configure something extra for ipv6 as my all settingsare defaultBest RegardsDigambar RasalControlnet India Pvt LtdIndia+91-832-883601
need to export status_init from mod_status/scoreboard
status_init() in mod_status initializes status_flags, server_limit and thread_limit. This is all nice for mod_status since it gets loaded before any threads are started. Under mod_perl Apache::Scoreboard (the Perl interface for scoreboard) can be loaded directly by the spawned threads. Therefore to avoid race condition one has to handle this with apr_thread_init_once, add the logic for prefork and you end up with an ugly code. Can we change mod_status or scoreboard to export these variables similar to ap_scoreboard_image or export functions that will return these variables, which will tremendously simplify things? I'll create and post a patch if you think it's a goodness. If so please tell me the preferred way to do this. also any chance somebody will respond/commit my other scoreboard/mod_status patches I've sent earlier? Thanks _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
mod_autoindex with css support, patch
Hi, I've made a simple patch to Apache 2.x mod_autoindex. It adds a new directive specifying a css file to use for the generated index. As I'm total newbie I would know your opinions. Thanks. R.Matl __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com autoindex_patch.tgz Description: autoindex_patch.tgz
Re: [PATCH] First cut at factoring out the pools allocator
On Tue, Mar 05, 2002 at 10:02:55AM +0100, Sander Striker wrote: Hi, Below a patch to apr and a patch to httpd to factor out the allocator from pools. It is only the first cut, so crucial details like documentation are missing. I'd like some feedback on the general idea though. Hopefully this helps when implementing the bucket allocator. +1. I like the API. Brian's suggestion is goodness, but shouldn't stop this from going in. Two slight implementation problems: - apr_thread_mutex.h is now a dependency of apr_allocator.h. That means it can't use APR_POOL_DECLARE_ACCESSOR since apr_pools.h requires this file. So, I just expanded the declaration in apr_thread_mutex.h. I'll leave it up to you how to resolve this (either expand it there or move the DECLARE macro somewhere else). I think if we put a big XXX in that file and expand it, we should be okay for now. (Perhaps with a note near the POOL_DECLARE definition that apr_thread_mutex.h is a special exception.) - I think APR_POOL_DEBUG isn't working. Namely the apr_pool_create_ex prototype is wrong. And, I think the API is fine considering that this gives the bucket code a chance to use it. So, please commit at your earliest chance. =) -- justin
Re: [PATCH] Solaris sockets for support/ab.c (httpd-2_0_32-beta)
On Wed, Mar 13, 2002 at 07:05:45AM -0500, Jeff Trawick wrote: Martin Ramshaw [EMAIL PROTECTED] writes: By default, Solaris (at least, Solaris 7 for sparc) restricts the number of file handles that may be used. See the comments in the attached patch file for more details. Lots of Unix-ish systems work the same way. Personally, I think it is better if you put ulimit -n unlimited in your shell init script rather than adding the logic to ab. Yup, my thoughts too. -- justin (wondering why I'm still up)
Re: [patch server/scoreboard.c] creating ws-thread_num
Stas Bekman [EMAIL PROTECTED] writes:
I don't think ws-thread_num has anything to do with server_limit. Am
I wrong?
Index: server/scoreboard.c
===
RCS file: /home/cvspublic/httpd-2.0/server/scoreboard.c,v
retrieving revision 1.60
diff -u -r1.60 scoreboard.c
--- server/scoreboard.c 27 Feb 2002 04:10:19 - 1.60
+++ server/scoreboard.c 12 Mar 2002 09:55:52 -
@@ -429,7 +429,7 @@
if (status == SERVER_READY
old_status == SERVER_STARTING) {
-ws-thread_num = child_num * server_limit + thread_num;
+ws-thread_num = child_num * thread_limit + thread_num;
you're right, of course :)
Worker MPM does the calculation the same way.
committed...
Thanks!
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
Re: how to debug worker mpm httpd with gdb?
My 2 cents: Keep using Linux when a fast build time is imperative or you're debugging non-threaded apps. Use AIX or Solaris with native tools when you want to debug threaded apps. It sucks :( -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [patch modules/generators/mod_status.c]
Stas Bekman [EMAIL PROTECTED] writes: On Mon, 11 Mar 2002, Stas Bekman wrote: this looks like a copy-n-paste porting bug. in httpd-2.0's scoreboard stop/start timestamps are in apr_time_t (==usecs only). the problem wasn't noticed before since these structures are never set in workers. Any ideas why? See mod_status's output for yourself. because unlike apache 1.3, nobody calls ap_time_process_request() :) (no idea why) here is one more porting leftover fix, including the previous one: Index: modules/generators/mod_status.c === RCS file: /home/cvspublic/httpd-2.0/modules/generators/mod_status.c,v retrieving revision 1.54 diff -u -r1.54 mod_status.c --- modules/generators/mod_status.c 4 Mar 2002 10:46:22 - 1.54 +++ modules/generators/mod_status.c 11 Mar 2002 09:43:25 - @@ -570,13 +570,11 @@ req_time = 0L; #endif /* HAVE_TIMES */ #else -if (ws_record.start_time == 0L - ws_record.start_time == 0L) +if (ws_record.start_time == 0L) req_time = 0L; else req_time = (long) -(((ws_record.stop_time - ws_record.start_time) * 1000) -+ ((ws_record.stop_time - ws_record.start_time) / 1000)); +((ws_record.stop_time - ws_record.start_time) / 1000); #endif if (req_time 0L) req_time = 0L; I'll commit this shortly. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: status of mod_status
Stas Bekman [EMAIL PROTECTED] writes:
oops, should have mentioned which code I was referring to.
The ifdef HAVE_TIMES part of a code snippet seems to be irrelevant
(includes my previously posted patch as well):
Index: modules/generators/mod_status.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/generators/mod_status.c,v
retrieving revision 1.54
diff -u -r1.54 mod_status.c
--- modules/generators/mod_status.c 4 Mar 2002 10:46:22 - 1.54
+++ modules/generators/mod_status.c 11 Mar 2002 17:04:43 -
@@ -558,26 +558,12 @@
ws_record = ap_scoreboard_image-servers[i][j];
ps_record = ap_scoreboard_image-parent[i];
-#if defined(NO_GETTIMEOFDAY)
-#ifdef HAVE_TIMES
-if (ws_record.start_time == (clock_t)0)
-req_time = 0L;
-else {
-req_time = ws_record.stop_time - ws_record.start_time;
-req_time = (req_time * 1000) / (int)tick;
-}
-#else
I just committed the deletion of the NO_GETTIMEOFDAY support.
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
Re: [PATCH] First cut at factoring out the pools allocator
Justin Erenkrantz wrote: On Tue, Mar 05, 2002 at 10:02:55AM +0100, Sander Striker wrote: Hi, Below a patch to apr and a patch to httpd to factor out the allocator from pools. It is only the first cut, so crucial details like documentation are missing. I'd like some feedback on the general idea though. Hopefully this helps when implementing the bucket allocator. +1. I like the API. Brian's suggestion is goodness, but shouldn't stop this from going in. +1. I think we'll need to implement my suggestion (a variant of the allocation function that reserves space for the internal header struct but still stays within 8KB) in support of the bucket free lists, but that that's a simple, additive change that we can put in later--so +1 on committing Sander's new allocator API now. --Brian
RE: [PATCH] First cut at factoring out the pools allocator
From: Brian Pane [mailto:[EMAIL PROTECTED]] Sent: 13 March 2002 15:59 Justin Erenkrantz wrote: On Tue, Mar 05, 2002 at 10:02:55AM +0100, Sander Striker wrote: Hi, Below a patch to apr and a patch to httpd to factor out the allocator from pools. It is only the first cut, so crucial details like documentation are missing. I'd like some feedback on the general idea though. Hopefully this helps when implementing the bucket allocator. +1. I like the API. Brian's suggestion is goodness, but shouldn't stop this from going in. +1. I think we'll need to implement my suggestion (a variant of the allocation function that reserves space for the internal header struct but still stays within 8KB) in support of the bucket free lists, but that that's a simple, additive change that we can put in later--so +1 on committing Sander's new allocator API now. Ok, I'll try and get it in tonight. I'm not entirely sure we need the extra allocation function though, but we can decide on that later. Sander
Re: [PATCH] Solaris sockets for support/ab.c (httpd-2_0_32-beta)
On Wed, 13 Mar 2002 04:18:00AM -0800, Justin Erenkrantz wrote: On Wed, Mar 13, 2002 at 07:05:45AM -0500, Jeff Trawick wrote: Martin Ramshaw [EMAIL PROTECTED] writes: By default, Solaris (at least, Solaris 7 for sparc) restricts the number of file handles that may be used. See the comments in the attached patch file for more details. Lots of Unix-ish systems work the same way. Personally, I think it is better if you put ulimit -n unlimited in your shell init script rather than adding the logic to ab. Yup, my thoughts too. -- justin (wondering why I'm still up) I see. So if I want to use 'ab' in a meaningful way on a 'Unix-ish system' I should write a shell wrapper script. Is it just me, or does that sound kind of lame ? Thanks for the feedback. Regards
[PATCH] ssl_engine_vars.c
'just did a cvs update and found that SSL_SESSION_id2sz in ssl_engine_vars.c
has fewer parameters than required.
-Madhu
Index: ssl_engine_vars.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/ssl/ssl_engine_vars.c,v
retrieving revision 1.14
diff -u -r1.14 ssl_engine_vars.c
--- ssl_engine_vars.c 12 Mar 2002 21:10:18 - 1.14
+++ ssl_engine_vars.c 13 Mar 2002 16:51:37 -
-282,10 +282,13
result = (char *)SSL_get_version(ssl);
}
else if (ssl != NULL strcEQ(var, SESSION_ID)) {
+char buf[SSL_SESSION_ID_STRING_LEN];
+
SSL_SESSION *pSession = SSL_get_session(ssl);
result = apr_pstrdup(p, SSL_SESSION_id2sz(
SSL_SESSION_get_session_id(pSession),
-
SSL_SESSION_get_session_id_length(pSession)));
+
SSL_SESSION_get_session_id_length(pSession),
+buf, sizeof(buf)));
}
else if (ssl != NULL strlen(var) = 6 strcEQn(var, CIPHER, 6))
{
result = ssl_var_lookup_ssl_cipher(p, c, var+6);
Re: need to export status_init from mod_status/scoreboard
On Wed, Mar 13, 2002 at 05:12:58PM +0800, Stas Bekman wrote: status_init() in mod_status initializes status_flags, server_limit and thread_limit. This is all nice for mod_status since it gets loaded before any threads are started. Under mod_perl Apache::Scoreboard (the Perl interface for scoreboard) can be loaded directly by the spawned threads. Therefore to avoid race condition one has to handle this with apr_thread_init_once, add the logic for prefork and you end up with an ugly code. Can we change mod_status or scoreboard to export these variables similar to ap_scoreboard_image or export functions that will return these variables, which will tremendously simplify things? +1 for accessor functions. -aaron
Re: [PATCH] ssl_engine_vars.c
On Wed, 13 Mar 2002, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: 'just did a cvs update and found that SSL_SESSION_id2sz in ssl_engine_vars.c has fewer parameters than required. whoops, my bad. thanks, applied.
Re: [PATCH] Solaris sockets for support/ab.c (httpd-2_0_32-beta)
Martin Ramshaw [EMAIL PROTECTED] writes: On Wed, 13 Mar 2002 04:18:00AM -0800, Justin Erenkrantz wrote: On Wed, Mar 13, 2002 at 07:05:45AM -0500, Jeff Trawick wrote: Martin Ramshaw [EMAIL PROTECTED] writes: By default, Solaris (at least, Solaris 7 for sparc) restricts the number of file handles that may be used. See the comments in the attached patch file for more details. Lots of Unix-ish systems work the same way. Personally, I think it is better if you put ulimit -n unlimited in your shell init script rather than adding the logic to ab. Yup, my thoughts too. -- justin (wondering why I'm still up) I see. So if I want to use 'ab' in a meaningful way on a 'Unix-ish system' I should write a shell wrapper script. That is not true in general. Plenty of people use ab on Unix and I've never heard a complaint about not being able to get enough file descriptors. Anyway, I didn't mean a shell wrapper script. I mean that you could/should put ulimit -n unlimited in your .profile/.bashrc/whatever. Is it just me, or does that sound kind of lame ? Some thoughts: The operating system has tools to adjust resource limits. Why should Apache and its support code duplicate that work? We can't do a better job than the OS and we end up with more code to maintain, most of it non-portable. If somebody wants to use ab to pound on a server with many concurrent connections, getting ab enough file descriptors is only one of their problems. Here are some others that they may or may not encounter depending on their OS and how they have changed the defaults: 1) configure enough file descriptors for the server (Apache has no such logic to adjust ulimit) 2) configure enough ephemeral ports on the client stack (on many OSs with the default configuration you can't run ab very long before ab can no longer connect to the server) 3) disable SYN attack code on the server stack so it doesn't get upset that so many SYNs for the same server port are coming from the same client 4) configure enough mbufs on the client stack so that the stack can actually create as many sockets as you are telling ab that it needs (on my FreeBSD 3.4 box I ended up recompiling the kernel to achieve this :( ) If Apache and support utilities have logic to adjust resource limits, developers can no longer adjust soft limits to force error paths. (There are always hard limits; by changing soft limits and not having Apache undo our change, we can easily simulate reaching the hard limit.) I hope this helps understand the big picture (at least as I see it). -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: need to export status_init from mod_status/scoreboard
Aaron Bannert wrote: On Wed, Mar 13, 2002 at 05:12:58PM +0800, Stas Bekman wrote: status_init() in mod_status initializes status_flags, server_limit and thread_limit. This is all nice for mod_status since it gets loaded before any threads are started. Under mod_perl Apache::Scoreboard (the Perl interface for scoreboard) can be loaded directly by the spawned threads. Therefore to avoid race condition one has to handle this with apr_thread_init_once, add the logic for prefork and you end up with an ugly code. Can we change mod_status or scoreboard to export these variables similar to ap_scoreboard_image or export functions that will return these variables, which will tremendously simplify things? +1 for accessor functions. regarding status_flags, should the accessor return a copy of the whole structure or just a pointer to it? where should the accessors reside: scoreboard or mod_status? Assuming that someone may want to use them without loading mod_status I think scoreboard is the right place and mod_status itself can use these. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
ap_sub_req_lookup_dirent
What is the purpose of calling ap_process_request_internal() in ap_sub_req_lookup_dirent()? Bill
RE: ap_sub_req_lookup_dirent
We call that function in all of the ap_sub_req_lookup functions. The purpose is to run all of the hooks that are required for creating a request successfully. Ryan What is the purpose of calling ap_process_request_internal() in ap_sub_req_lookup_dirent()? Bill
Re: need to export status_init from mod_status/scoreboard
Stas Bekman wrote: where should the accessors reside: scoreboard or mod_status? Assuming that someone may want to use them without loading mod_status I think scoreboard is the right place and mod_status itself can use these. Scoreboard totally. mod_status would be just one possible user. I can envision other modules enjoying that data :) -- === 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: ap_sub_req_lookup_dirent
ap_process_request_internal() is called at the very end of ap_sub_req_lookup() and I don't see that it is providing any additional information that is not already available prior to the call (ie, we already have stat'ed the file and know all the finfo required by the caller). The only useful thing that I see happening is authentication. Otherwise, we do not want to run translate_name or most of the other hooks as far as I can see... Bill We call that function in all of the ap_sub_req_lookup functions. The purpose is to run all of the hooks that are required for creating a request successfully. Ryan What is the purpose of calling ap_process_request_internal() in ap_sub_req_lookup_dirent()? Bill
RE: ap_sub_req_lookup_dirent
ap_process_request_internal() is called at the very end of ap_sub_req_lookup() and I don't see that it is providing any additional information that is not already available prior to the call (ie, we already have stat'ed the file and know all the finfo required by the caller). The only useful thing that I see happening is authentication. Otherwise, we do not want to run translate_name or most of the other hooks as far as I can see... We have to run all of the hooks, from translate_name through fixups for all sub-requests. While translate_name shouldn't do anything for a lookup_dirent call, all of the auth hooks, type_checker, and fixups can all modify the request. By calling ap_process_request_internal the code is simplified, because there is only one way to go through request processing. The previous solution had a different path for every subrequest mechanism. Ryan Bill We call that function in all of the ap_sub_req_lookup functions. The purpose is to run all of the hooks that are required for creating a request successfully. Ryan What is the purpose of calling ap_process_request_internal() in ap_sub_req_lookup_dirent()? Bill
putting mod_scoreboard_send in core?
The Apache::Scoreboard distribution for 1.x includes mod_scoreboard_send.c, which allows you to collect the scoreboards from many machines for various purposes. This is a special standalone C version which doesn't require mod_perl. There is a C code which freeze()s the scoreboard and sends it to the client, which can then be thaw()ed to retrieve the scoreboard. Apache::Scoreboard is now going to be folded into the mod_perl 2.0 core, therefore we cannot distribute mod_scoreboard_send.c any longer since there is no Apache-Scoreboard distribution. And those who will want to use mod_scoreboard_send.c won't want to grab mod_perl sources for it. We think that the best place for this module is in the core. I haven't ported it to 2.0 yet, and plan to do it shortly. It's a very small modules. Where should it go: modules/generators/mod_scoreboard_send? p.s. all this cool stuff is a courtesy of Doug MacEachern, I'm just porting it to 2.0 ;) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Strange autoindex behaviour
I can't imagine that it is normal/desireable for autoindex to recurse through subdirectories in the directory to be indexed. For instance I am autoindexing c:/website. c:/website has a number of subdirectories. ap_process_request_internal() called out of ap_sub_req_lookup_dirent() is recursing through the entire directory structures of the directories under c:/website. Is there a valid reason for the code to be behaving this way? Bill
Re: Strange autoindex behaviour
Upon closer inspection... the code is looking for index.html and index.html.var in each subdirectory. Havent tested to see how far down the code will recurse.. This is just goofy. Bill I can't imagine that it is normal/desireable for autoindex to recurse through subdirectories in the directory to be indexed. For instance I am autoindexing c:/website. c:/website has a number of subdirectories. ap_process_request_internal() called out of ap_sub_req_lookup_dirent() is recursing through the entire directory structures of the directories under c:/website. Is there a valid reason for the code to be behaving this way? Bill
PR 10163, location of config_vars.mk
short form: I want to move config_vars.mk from top_builddir to top_builddir/build/config_vars.mk. Okay? long form: PR 10163 deals with some hard-coded paths that broke the makefile created by apxs -g. I just committed what ordinarily would make it work, except for a basic problem: . Apache build puts config_vars.mk in top_builddir . Apache install puts config_vars.mk in prefix/build . apxs wants to use snippets of Apache build support (e.g., rules.mk) which assume that config_vars.mk is not in the build subdirectory To get apxs's use of rules.mk et al to work config_vars.mk needs to be in a consistent place (in or out of the build subdirectory for both Apache build and the installed copy of config_vars.mk). The easiest fix is to install config_vars.mk into prefix, but that is ugly. Always putting it in the build subdirectory seems nicer. But I can't help but wonder why it isn't there already. Are there any problems with that? -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: ap_sub_req_lookup_dirent
ap_process_request_internal() is called at the very end of ap_sub_req_lookup() and I don't see that it is providing any additional information that is not already available prior to the call (ie, we already have stat'ed the file and know all the finfo required by the caller). The only useful thing that I see happening is authentication. Otherwise, we do not want to run translate_name or most of the other hooks as far as I can see... We have to run all of the hooks, from translate_name through fixups for all sub-requests. While translate_name shouldn't do anything for a lookup_dirent call, all of the auth hooks, type_checker, and fixups can all modify the request. By calling ap_process_request_internal the code is simplified, because there is only one way to go through request processing. The previous solution had a different path for every subrequest mechanism. Ryan I am not an expert in this area, but it appears that we skip running a lot of the hooks in ap_process_request_internal depending on whether the request is a subrequest or not (and the check for subrequests is very coarse grained, precluding the possibility of selectively handling different subrequests differently. For instance, a dirent subrequest should not call the quick handler ever... perhaps it is okay for other subrequests to call quick_handler... Bill
RE: Strange autoindex behaviour
Upon closer inspection... the code is looking for index.html and index.html.var in each subdirectory. Havent tested to see how far down the code will recurse.. This is just goofy. That is goofy, but the reason it is happening, is because we redirect to the index.html page from the fixups hook. I can't remember if this used to happen in 1.3 or not. Ryan Bill I can't imagine that it is normal/desireable for autoindex to recurse through subdirectories in the directory to be indexed. For instance I am autoindexing c:/website. c:/website has a number of subdirectories. ap_process_request_internal() called out of ap_sub_req_lookup_dirent() is recursing through the entire directory structures of the directories under c:/website. Is there a valid reason for the code to be behaving this way? Bill
Re: putting mod_scoreboard_send in core?
a few notes on this.. the purpose of mod_scoreboard_send was to download the scoreboard image on a remote machine. the scoreboard image was then used on the client machine to generate fancy graphical images to make our boss feel like he knew what was going on. sorta like a graphical mod_status, but could also combine stats of a server farm into one browser window. anyhoo, the module should not go in as-is, it was designed to incur as little overhead as possible, pretty much sends the binary data as-is. and hence isn't portable since it uses native byte order rather than network order. which was ok for us since the client machine was the same architecture as the servers. and the concept might not apply at all to the 2.0 scoreboard, i haven't looked at it. in general, the concept is to serialize the scoreboard in such a way that it can transfered over the network via http and thawed on another machine. i'm sure there's a better way to do this than the mod_scoreboard_send thinger.
Re: [1.3 PATCH/QUESTION] Win32 ap_os_is_filename_valid()
Jeff Trawick [EMAIL PROTECTED] writes: This function is checking for several characters which, at least in ASCII, are supposedly not valid characters for filenames. But some of these same characters can appear in valid non-ASCII filenames, and the logic to check for these characters breaks Apache's ability to serve those files. A user reported the inability to request a file with the Chinese character %b5%7c in the name. The %7c byte tripped up the check for invalid ASCII characters. I think this is an accurate statement regarding the use of non-ASCII characters in filenames with Apache 1.3 on Win32. Comments? ---cut here-- Names of file-based resources with Apache 1.3 on Win32 Apache 1.3 on Win32 assumes that the names of files served are comprised solely of characters from the US-ASCII character set. It has no logic to determine whether or not a possible file name contains invalid non-ASCII characters. It has no logic to properly match actual non-ASCII file names with names specified in the Apache configuration file. Because Apache does not verify that the characters in file names are all ASCII, files files containing various non-ASCII characters in their names can be successfully served by Apache. However, this is not recommended for the following reasons: 1) Because Apache is unable to properly match actual non-ASCII file names with names in the Apache configuration file, taking into account any case folding or other transformations handled by the operating system when looking up files or otherwise matching file names, directives in the Apache configuration file may or may not be in force, depending on how the HTTP client specifies the resource. This may be a security concern, depending on your configuration. 2) Because Apache assumes that file names are ASCII, some of the checks it makes when validating file names will flag certain non-ASCII characters as invalid. For example, Apache on Win32 will flag a file name containing the ASCII character '|' (0x7C) as invalid. This logic will flag any file name containing the byte 0x7C as invalid, even if that byte does not represent '|' in the local character set. There are other characters checked for as well. Because of these checks, even if there are no security issues in your configuration, the full range of local characters cannot be used. Because of the lack of proper support for non-ASCII characters in file names, it is recommended that administrators not attempt to use any non-ASCII characters in file names. Any other configuration is unsupported. --cut here -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: putting mod_scoreboard_send in core?
On Wed, 13 Mar 2002, Doug MacEachern wrote: in general, the concept is to serialize the scoreboard in such a way that it can transfered over the network via http and thawed on another machine. i'm sure there's a better way to do this than the mod_scoreboard_send thinger. I have done this in two ways with tools that are not in the httpd core. - have SNMP polls to mod_nsmp(1) and then display it using MRTG, HP OpenView Scotty, or whatever - use mod_status_xml(2) and do periodic GET and use XSLT/SVG to merge the content into a pretty graph/HTML page. I really do not see why this needs to be in the httpd core. 1) the SNMPv3 capable http://www.covalent.net/products/managed/ or http://www.simpleweb.org/software/packages/mod-snmp/ 2) http://www.awe.com/mark/dev/mod_status_xml/ with some contributed changes. -- Sander van Zoest [EMAIL PROTECTED] San Diego, CA, US http://Sander.vanZoest.com/
Re: [1.3 PATCH/QUESTION] Win32 ap_os_is_filename_valid()
On Wed, Mar 13, 2002 at 02:12:18PM -0500, Jeff Trawick wrote: Jeff Trawick [EMAIL PROTECTED] writes: This function is checking for several characters which, at least in ASCII, are supposedly not valid characters for filenames. But some of these same characters can appear in valid non-ASCII filenames, and the logic to check for these characters breaks Apache's ability to serve those files. A user reported the inability to request a file with the Chinese character %b5%7c in the name. The %7c byte tripped up the check for invalid ASCII characters. I think this is an accurate statement regarding the use of non-ASCII characters in filenames with Apache 1.3 on Win32. Comments? Doesn't 2.0 support this properly on Win32? Couldn't that just be our recommendation? -- justin
mod_mime_magic question
Hi, I'm developing an application that needs functionality almost the same as Apache's mod_mime_magic module - to guess file MIME type from file. And since I'm lazy I want to use mod_mime_magic module in my application. But I have some questions: 1) licensing issues (what should I do to comply with Apache license) 2) I'm not C/C++ programmer, I'm programming in Pascal (under Win32) and I ask someone to help me with this work (at least to explain what to do - I have basic knowledge of C and probably will be able to make DLL) My application is called Futuris Imager: http://futuris.plastiqueweb.com/ -- Alexander Tereschenko http://futuris.plastiqueweb.com/ Dying tickles ! (from The Simpsons)
Re: Copyright year bumping
On Sat, Mar 09, 2002 at 12:20:23PM +0800, Stas Bekman wrote:
Sander Striker wrote:
Hi,
Should we bump the copyright year on all the files?
Anyone have a script handy?
find . -type f -exec perl -pi -e 's|2000-2001|2000-2002|' {} \;
That would change a lot more, and a lot less, than we want. I've committed
the change for 2.0 and will do 1.3 next.
Roy
Re: Strange autoindex behaviour
Should we even be calling the fixup hook on a dirent subrequest? Bill Upon closer inspection... the code is looking for index.html and index.html.var in each subdirectory. Havent tested to see how far down the code will recurse.. This is just goofy. That is goofy, but the reason it is happening, is because we redirect to the index.html page from the fixups hook. I can't remember if this used to happen in 1.3 or not. Ryan Bill I can't imagine that it is normal/desireable for autoindex to recurse through subdirectories in the directory to be indexed. For instance I am autoindexing c:/website. c:/website has a number of subdirectories. ap_process_request_internal() called out of ap_sub_req_lookup_dirent() is recursing through the entire directory structures of the directories under c:/website. Is there a valid reason for the code to be behaving this way? Bill
Re: Content-length returned from HEAD requests?
On Tue, Mar 12, 2002 at 10:57:50AM -0800, Brian Pane wrote: Aaron Bannert wrote: Is it valid for Content-length to be returned from these types of requests? daedalus is showing it, and I'm seeing it in current CVS. -aaron I don't think so, unless it's Content-Length: 0, due to this part of section 10.2.7 in RFC 2616: If a Content-Length header field is present in the response, its value MUST match the actual number of OCTETs transmitted in the message-body. That section is on the 206 response, not a 200 response. Section 4.3: For response messages, whether or not a message-body is included with a message is dependent on both the request method and the response status code (section 6.1.1). All responses to the HEAD request method MUST NOT include a message-body, even though the presence of entity- header fields might lead one to believe they do. All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a message-body. All other responses do include a message-body, although it MAY be of zero length. 4.4 Message Length The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings have been applied. When a message-body is included with a message, the transfer-length of that body is determined by one of the following (in order of precedence): 1.Any response message which MUST NOT include a message-body (such as the 1xx, 204, and 304 responses and any response to a HEAD request) is always terminated by the first empty line after the header fields, regardless of the entity-header fields present in the message. Roy
Re: [1.3 PATCH/QUESTION] Win32 ap_os_is_filename_valid()
Justin Erenkrantz [EMAIL PROTECTED] writes: On Wed, Mar 13, 2002 at 02:12:18PM -0500, Jeff Trawick wrote: Jeff Trawick [EMAIL PROTECTED] writes: This function is checking for several characters which, at least in ASCII, are supposedly not valid characters for filenames. But some of these same characters can appear in valid non-ASCII filenames, and the logic to check for these characters breaks Apache's ability to serve those files. A user reported the inability to request a file with the Chinese character %b5%7c in the name. The %7c byte tripped up the check for invalid ASCII characters. I think this is an accurate statement regarding the use of non-ASCII characters in filenames with Apache 1.3 on Win32. Comments? Doesn't 2.0 support this properly on Win32? Couldn't that just be our recommendation? -- justin I *think* it works properly on Win32 in Apache 2.0, but I just don't know :( OtherBill? -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: PR 10163, location of config_vars.mk
On Wed, Mar 13, 2002 at 01:09:27PM -0500, Jeff Trawick wrote: short form: I want to move config_vars.mk from top_builddir to top_builddir/build/config_vars.mk. Okay? +1 Roy
Re: [1.3 PATCH/QUESTION] Win32 ap_os_is_filename_valid()
On Wed, Mar 13, 2002 at 02:12:18PM -0500, Jeff Trawick wrote: Jeff Trawick [EMAIL PROTECTED] writes: This function is checking for several characters which, at least in ASCII, are supposedly not valid characters for filenames. But some of these same characters can appear in valid non-ASCII filenames, and the logic to check for these characters breaks Apache's ability to serve those files. A user reported the inability to request a file with the Chinese character %b5%7c in the name. The %7c byte tripped up the check for invalid ASCII characters. I think this is an accurate statement regarding the use of non-ASCII characters in filenames with Apache 1.3 on Win32. Comments? ---cut here-- Names of file-based resources with Apache 1.3 on Win32 Apache 1.3 on Win32 assumes that the names of files served are comprised solely of characters from the US-ASCII character set. It has no logic to determine whether or not a possible file name contains invalid non-ASCII characters. It has no logic to properly match actual non-ASCII file names with names specified in the Apache configuration file. Because Apache does not verify that the characters in file names are all ASCII, files files containing various non-ASCII characters in their names can be successfully served by Apache. However, this is not recommended for the following reasons: No, it doesn't. It treats all names as raw bytes, regardless of charset, but the filtering process of preventing some filesystem-specific magic characters from creating security holes on a server prevents the use of unfiltered 16-bit Unicode or similar wide character sets from being used directly. This is true in general for the Web -- wide character encodings are not allowed to appear in URI under any circumstances. The solution is to use UTF-8 encoding for non-ASCII characters and not allow any access via wide character function calls. Roy
[PATCH] Do not run fixups against dirent subrequests
I really don't like this patch because it stinks of creeping hacks built upon hacks
but it
should suffice to get a discussion going.
This patch fixes a bug where a directory index of c:/website causes subrequests to be
generated searching for index.html and index.html.var files under subdirs in
c:/website.
(and the bug totally hoses up directory indexing when mod_cache is enabled).
Thoughts?
Bill
Index: request.c
===
RCS file: /home/cvs/httpd-2.0/server/request.c,v
retrieving revision 1.105
diff -u -r1.105 request.c
--- request.c 13 Mar 2002 19:41:56 - 1.105
+++ request.c 13 Mar 2002 21:33:39 -
-302,8 +302,11
return decl_die(access_status, find types, r);
}
-if ((access_status = ap_run_fixups(r)) != 0) {
-return access_status;
+/* Don't run fixups on a dirent subrequest */
+if (!file_req !r-finfo.filetype) {
+if ((access_status = ap_run_fixups(r)) != 0) {
+return access_status;
+}
}
return OK;
New module for Apache 2.0?
Hi guys, I have mod_hf, which adds a header or footer to every page that the server sends. It is also a pretty good example of how write a filter for 2.0. Would anybody mind if I committed that to modules/fitlers? If not, I will just maintain it myself. Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA
Re: New module for Apache 2.0?
I'm 0 for in modules/filters and +1 for modules/experimental :) Ryan Bloom wrote: Hi guys, I have mod_hf, which adds a header or footer to every page that the server sends. It is also a pretty good example of how write a filter for 2.0. Would anybody mind if I committed that to modules/fitlers? If not, I will just maintain it myself. Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA -- === 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: New module for Apache 2.0?
On Wed, Mar 13, 2002 at 02:14:54PM -0800, Ryan Bloom wrote: I have mod_hf, which adds a header or footer to every page that the server sends. It is also a pretty good example of how write a filter for 2.0. Would anybody mind if I committed that to modules/fitlers? If not, I will just maintain it myself. If it's an example, I want to see it in our repository, useful or not. If it becomes more than an example at some point, we could just move it out of experimental or test or a new example modules dir or whatnot. -aaron
Re: New module for Apache 2.0?
Does it just add the header/footer at the start/end of the content, or does it parse the HTML so that it can include them inside the body.../body block? If it parses the HTML, +1 on adding it to modules/filters. If not, I'm not sure how generally useful it would be, but +1 on including it in modules/example at the very least. It would be really nice to have something less complex than mod_include to use as an example of how to write a filter. :-) --Brian Ryan Bloom wrote: Hi guys, I have mod_hf, which adds a header or footer to every page that the server sends. It is also a pretty good example of how write a filter for 2.0. Would anybody mind if I committed that to modules/fitlers? If not, I will just maintain it myself. Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA
Re: New module for Apache 2.0?
On Wed, Mar 13, 2002 at 02:14:54PM -0800, Ryan Bloom wrote: Hi guys, I have mod_hf, which adds a header or footer to every page that the server sends. It is also a pretty good example of how write a filter for 2.0. Would anybody mind if I committed that to modules/fitlers? If not, I will just maintain it myself. Sounds cool. I'd suggest modules/experimental (as that is where we stuck deflate too and it is a filter). -- justin
Re: [PATCH] Solaris sockets for support/ab.c (httpd-2_0_32-beta)
snip I hope this helps understand the big picture (at least as I see it). It does, and thank you for taking the time to explain this to me. My hope was to be able to foist off benchmarking onto someone else, which isn't really an option if too much configuration (i.e. scripting) is required. My frustration was that (as you confirmed) a benchmarking effort involves benchmarking the machine driving the benchmark (i.e. running 'ab') as much as anything else. Of course, this is less of an issue now that Solaris Intel is to be mothballed. Unfortunately, benchmarking (MTBF, Average and distributed response times, whether failure is graceful or not, suggested hardware platform for desired performance, etc, etc) quickly turns into a study in comparative operating systems. NT starts rejecting connections at around 58 concurrent connections; it turns out that NT is not a *true* multi-threaded OS at all but has an internal limit of 64 concurrencies, some of which it needs itself. My experience with other OS's is that they gracefully start rejecting connections at a much higher level of concurrency. Best regards
RE: New module for Apache 2.0?
Currently, it doesn't parse the HTML for the body.../body block, but it shouldn't be too hard to add that logic. Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA -Original Message- From: Brian Pane [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 13, 2002 2:24 PM To: [EMAIL PROTECTED] Subject: Re: New module for Apache 2.0? Does it just add the header/footer at the start/end of the content, or does it parse the HTML so that it can include them inside the body.../body block? If it parses the HTML, +1 on adding it to modules/filters. If not, I'm not sure how generally useful it would be, but +1 on including it in modules/example at the very least. It would be really nice to have something less complex than mod_include to use as an example of how to write a filter. :-) --Brian Ryan Bloom wrote: Hi guys, I have mod_hf, which adds a header or footer to every page that the server sends. It is also a pretty good example of how write a filter for 2.0. Would anybody mind if I committed that to modules/fitlers? If not, I will just maintain it myself. Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA
Re: [1.3 PATCH/QUESTION] Win32 ap_os_is_filename_valid()
Roy T. Fielding [EMAIL PROTECTED] writes: On Wed, Mar 13, 2002 at 02:12:18PM -0500, Jeff Trawick wrote: Jeff Trawick [EMAIL PROTECTED] writes: This function is checking for several characters which, at least in ASCII, are supposedly not valid characters for filenames. But some of these same characters can appear in valid non-ASCII filenames, and the logic to check for these characters breaks Apache's ability to serve those files. A user reported the inability to request a file with the Chinese character %b5%7c in the name. The %7c byte tripped up the check for invalid ASCII characters. I think this is an accurate statement regarding the use of non-ASCII characters in filenames with Apache 1.3 on Win32. Comments? ---cut here-- Names of file-based resources with Apache 1.3 on Win32 Apache 1.3 on Win32 assumes that the names of files served are comprised solely of characters from the US-ASCII character set. It has no logic to determine whether or not a possible file name contains invalid non-ASCII characters. It has no logic to properly match actual non-ASCII file names with names specified in the Apache configuration file. Because Apache does not verify that the characters in file names are all ASCII, files files containing various non-ASCII characters in their names can be successfully served by Apache. However, this is not recommended for the following reasons: No, it doesn't. It treats all names as raw bytes, regardless of charset, but the filtering process of preventing some filesystem-specific magic characters from creating security holes on a server prevents the use of unfiltered 16-bit Unicode or similar wide character sets from being used directly. This is true in general for the Web -- wide character encodings are not allowed to appear in URI under any circumstances. The solution is to use UTF-8 encoding for non-ASCII characters and not allow any access via wide character function calls. Thanks a bunch for your response. I'm more than a little unclear on this stuff. Regarding your key comment treats all file names as raw bytes, regardless of charset... I would agree with that for Unix, but on Win32, in an attempt to match the semantics of the native filesystem (case preserving but not case significant), Apache will perform case transformations on file names*. This, along with the filtering code to check for specific ASCII values, is why I claimed that it assumes ASCII. *see ap_os_canonical_filename(), which is used to generate r-filename -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
[PATCH] SSL Session Caching stuff
Hi,
Good Afternoon !!. Another attempt at the SSL session caching stuff.. As
regards the patch,
1. enables shmht, shmcb in Apache 2.0 (complete in terms of compiling - but
may not be fully complete in terms of functionality)
2. Can somebody please review and tell me what may be wrong in the
apr_shm_*, apr_rmm_* logic that I've put in the
ssl_scache_shmht.c/ssl_scache_shmcb.c. I have a feeling that I'm missing
something important - I'm not doing the apr_shm_attach() / apr_rmm_attach.
3. I was able to bring up the server and get the session caching on linux
(redhat 7.2), but not on HP-UX :-(. The difference b/w Linux and HP-UX is
that Linux uses MMAP_ANON and HP-UX uses SHMGET. I think there's something
wrong in the apr_shm_create() logic - still looking into it.
4. There might be some non-portable issues - it'll be great if somebody
could pl. point it out to me.
Thanks,
-Madhu
Index: modules/ssl/mod_ssl.h
===
RCS file: /home/cvspublic/httpd-2.0/modules/ssl/mod_ssl.h,v
retrieving revision 1.79
diff -u -r1.79 mod_ssl.h
--- modules/ssl/mod_ssl.h 13 Mar 2002 20:47:54 - 1.79
+++ modules/ssl/mod_ssl.h 13 Mar 2002 23:07:15 -
@@ -108,6 +108,8 @@
#include apr_fnmatch.h
#include apr_strings.h
#include apr_dbm.h
+#include apr_rmm.h
+#include apr_shm.h
#include apr_optional.h
/* OpenSSL headers */
@@ -488,9 +490,8 @@
int nSessionCacheMode;
char *szSessionCacheDataFile;
int nSessionCacheDataSize;
-#if 0 /* XXX */
-AP_MM *pSessionCacheDataMM;
-#endif
+apr_shm_t *pSessionCacheDataMM;
+apr_rmm_t *pSessionCacheDataRMM;
apr_table_t*tSessionCacheDataTable;
ssl_mutexmode_t nMutexMode;
char *szMutexFile;
@@ -679,22 +680,22 @@
void ssl_scache_dbm_remove(server_rec *, UCHAR *, int);
void ssl_scache_dbm_expire(server_rec *);
void ssl_scache_dbm_status(server_rec *, apr_pool_t *, void (*)(char *, void
*), void *);
-#if 0 /* XXX */
-void ssl_scache_shmht_init(server_rec *, pool *);
+
+void ssl_scache_shmht_init(server_rec *, apr_pool_t *);
void ssl_scache_shmht_kill(server_rec *);
BOOL ssl_scache_shmht_store(server_rec *, UCHAR *, int, time_t, SSL_SESSION
*);
SSL_SESSION *ssl_scache_shmht_retrieve(server_rec *, UCHAR *, int);
void ssl_scache_shmht_remove(server_rec *, UCHAR *, int);
void ssl_scache_shmht_expire(server_rec *);
-void ssl_scache_shmht_status(server_rec *, pool *, void (*)(char *, void *),
void *);
-void ssl_scache_shmcb_init(server_rec *, pool *);
+void ssl_scache_shmht_status(server_rec *, apr_pool_t *, void (*)(char *,
+void *), void *);
+
+void ssl_scache_shmcb_init(server_rec *, apr_pool_t *);
void ssl_scache_shmcb_kill(server_rec *);
BOOL ssl_scache_shmcb_store(server_rec *, UCHAR *, int, time_t, SSL_SESSION
*);
SSL_SESSION *ssl_scache_shmcb_retrieve(server_rec *, UCHAR *, int);
void ssl_scache_shmcb_remove(server_rec *, UCHAR *, int);
void ssl_scache_shmcb_expire(server_rec *);
-void ssl_scache_shmcb_status(server_rec *, pool *, void (*)(char *, void *),
void *);
-#endif
+void ssl_scache_shmcb_status(server_rec *, apr_pool_t *, void (*)(char *,
+void *), void *);
/* Pass Phrase Support */
void ssl_pphrase_Handle(server_rec *, apr_pool_t *);
@@ -768,4 +769,5 @@
char*ssl_util_ptxtsub(apr_pool_t *, const char *, const char *, char *);
void ssl_util_thread_setup(server_rec *, apr_pool_t *);
+#define APR_SHM_MAXSIZE (64 * 1024 * 1024)
#endif /* __MOD_SSL_H__ */
Index: modules/ssl/ssl_engine_config.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/ssl/ssl_engine_config.c,v
retrieving revision 1.35
diff -u -r1.35 ssl_engine_config.c
--- modules/ssl/ssl_engine_config.c 13 Mar 2002 20:47:54 - 1.35
+++ modules/ssl/ssl_engine_config.c 13 Mar 2002 23:07:15 -
@@ -95,9 +95,8 @@
mc-nSessionCacheMode = SSL_SCMODE_UNSET;
mc-szSessionCacheDataFile = NULL;
mc-nSessionCacheDataSize = 0;
-#if 0 /* XXX */
mc-pSessionCacheDataMM= NULL;
-#endif
+mc-pSessionCacheDataRMM = NULL;
mc-tSessionCacheDataTable = NULL;
mc-nMutexMode = SSL_MUTEXMODE_UNSET;
mc-szMutexFile= NULL;
@@ -828,16 +827,10 @@
mc-nSessionCacheMode = SSL_SCMODE_DBM;
mc-szSessionCacheDataFile = ap_server_root_relative(mc-pPool, arg+4);
}
-else if (((arglen 4) strcEQn(arg, shm:, 4)) ||
- ((arglen 6) strcEQn(arg, shmht:, 6)))
-{
-#if 0 /* XXX */
-if (!ap_mm_useable()) {
-return SSLSessionCache: shared memory cache
- not useable on this platform;
-}
+else if ((arglen 6) strcEQn(arg, shmht:, 6)) {
+#if
Re: [1.3 PATCH/QUESTION] Win32 ap_os_is_filename_valid()
Regarding your key comment treats all file names as raw bytes, regardless of charset... I would agree with that for Unix, but on Win32, in an attempt to match the semantics of the native filesystem (case preserving but not case significant), Apache will perform case transformations on file names*. This, along with the filtering code to check for specific ASCII values, is why I claimed that it assumes ASCII. ISO-8859-1 or UTF-8 both contain ASCII as a subset. It is therefore more accurate to say that it assumes some character encoding that is a superset of ASCII, rather than just ASCII. It keeps you from getting your butt flamed by the i18n crowd as well. *see ap_os_canonical_filename(), which is used to generate r-filename Hey, I prefer to keep my sanity. I mentioned a while back that the way to do this right is to define directives for the Directory container that define when a directory tree is case insensitive, Unicode, etc., since this has very little to do with the operating system. Roy
Re: New module for Apache 2.0?
On Wed, Mar 13, 2002 at 02:14:54PM -0800, Ryan Bloom wrote: Hi guys, I have mod_hf, which adds a header or footer to every page that the server sends. It is also a pretty good example of how write a filter for 2.0. Would anybody mind if I committed that to modules/fitlers? If not, I will just maintain it myself. -0 for modules/filters +1 for modules/experimental If you do a modules/example/, then experimental/mod_example.c should move, too. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: putting mod_scoreboard_send in core?
Sander van Zoest wrote: On Wed, 13 Mar 2002, Doug MacEachern wrote: in general, the concept is to serialize the scoreboard in such a way that it can transfered over the network via http and thawed on another machine. i'm sure there's a better way to do this than the mod_scoreboard_send thinger. I have done this in two ways with tools that are not in the httpd core. - have SNMP polls to mod_nsmp(1) and then display it using MRTG, HP OpenView Scotty, or whatever - use mod_status_xml(2) and do periodic GET and use XSLT/SVG to merge the content into a pretty graph/HTML page. Both are cool, but compared to working with raw data they: 1. incur a huge overhead of creating xml or SNMP MIB compared to sending raw data. 2. won't let you use the same code one uses to work directly with scoreboard image. How about adding a new mode for mod_status, so it'll send a raw image on demand? This will not require a new module and sounds like a good thing to do. The scoreboard in 2.0 is not much different from 1.x so you can still freeze the raw data and thaw it later. Of course using the network byteorder needs to be added, which could be an option so those wanted the fastest retrieve times can still get the native byte ordering. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: ap_sub_req_lookup_dirent
Huh? Additional information not already available ??? Try authn/authz, for one. Or, how about Do we have a handler that can handle this resource? Or, 'hmm... Files .bak are never to be served. We must run the entire process_request_internal to know that a file listed in autoindex is servable. If you wanted a toggle for the operator to say, Hey, who cares, give me back the CPU cycle and they can see anything I'm foolish enough to put in those directories!!!, I'd be +1 for such a directive. And skip the lookup altogether. But that's -only- by choice, it should not be the default for the obvious security-related reasons. But you aren't describing anything that fancyindexing on 1.3 didn't already do. No surprise here. Bill At 11:48 AM 3/13/2002, you wrote: ap_process_request_internal() is called at the very end of ap_sub_req_lookup() and I don't see that it is providing any additional information that is not already available prior to the call (ie, we already have stat'ed the file and know all the finfo required by the caller). The only useful thing that I see happening is authentication. Otherwise, we do not want to run translate_name or most of the other hooks as far as I can see... Bill We call that function in all of the ap_sub_req_lookup functions. The purpose is to run all of the hooks that are required for creating a request successfully. Ryan What is the purpose of calling ap_process_request_internal() in ap_sub_req_lookup_dirent()? Bill
Re: Strange autoindex behaviour
The issue isn't mod_autoindex at all. Mod_dir is now implemented in terms of a fast_internal_redirect. This makes sense, when you consider that a subreq for /foo/ should return type text/html if that will be the results of a real request for /foo/. But in this -one- case, I see the issue/confusion. I would be very adverse to changing mod_dir back to returning whatever goofy application/x-unix-dir we had in 1.3, but we could agree to skip the subreq on a dir, if we can agree that requests for /foo/ that will error out or are protected are then displayed always. I doubt most admins want /foo/ listed if it is a protected resource, so the default needs to remain as-is with a full subreq lookup test. Upon closer inspection... the code is looking for index.html and index.html.var in each subdirectory. Havent tested to see how far down the code will recurse.. This is just goofy. That is goofy, but the reason it is happening, is because we redirect to the index.html page from the fixups hook. I can't remember if this used to happen in 1.3 or not. I can understand the redirect, but why the directory recursion? Let me look at what else using the dirent call... -- === 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: [1.3 PATCH/QUESTION] Win32 ap_os_is_filename_valid()
+1 ... feel free to profer that 2.0 introduces utf-8 convention to access any filenames and resources in a predictable and safe manner. Since APR does 99% of that magic, backporting that feature to 1.3 is not under consideration. Bill At 01:12 PM 3/13/2002, you wrote: Jeff Trawick [EMAIL PROTECTED] writes: This function is checking for several characters which, at least in ASCII, are supposedly not valid characters for filenames. But some of these same characters can appear in valid non-ASCII filenames, and the logic to check for these characters breaks Apache's ability to serve those files. A user reported the inability to request a file with the Chinese character %b5%7c in the name. The %7c byte tripped up the check for invalid ASCII characters. I think this is an accurate statement regarding the use of non-ASCII characters in filenames with Apache 1.3 on Win32. Comments? ---cut here-- Names of file-based resources with Apache 1.3 on Win32 Apache 1.3 on Win32 assumes that the names of files served are comprised solely of characters from the US-ASCII character set. It has no logic to determine whether or not a possible file name contains invalid non-ASCII characters. It has no logic to properly match actual non-ASCII file names with names specified in the Apache configuration file. Because Apache does not verify that the characters in file names are all ASCII, files files containing various non-ASCII characters in their names can be successfully served by Apache. However, this is not recommended for the following reasons: 1) Because Apache is unable to properly match actual non-ASCII file names with names in the Apache configuration file, taking into account any case folding or other transformations handled by the operating system when looking up files or otherwise matching file names, directives in the Apache configuration file may or may not be in force, depending on how the HTTP client specifies the resource. This may be a security concern, depending on your configuration. 2) Because Apache assumes that file names are ASCII, some of the checks it makes when validating file names will flag certain non-ASCII characters as invalid. For example, Apache on Win32 will flag a file name containing the ASCII character '|' (0x7C) as invalid. This logic will flag any file name containing the byte 0x7C as invalid, even if that byte does not represent '|' in the local character set. There are other characters checked for as well. Because of these checks, even if there are no security issues in your configuration, the full range of local characters cannot be used. Because of the lack of proper support for non-ASCII characters in file names, it is recommended that administrators not attempt to use any non-ASCII characters in file names. Any other configuration is unsupported. --cut here -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [1.3 PATCH/QUESTION] Win32 ap_os_is_filename_valid()
At 04:50 PM 3/13/2002, you wrote: Roy T. Fielding [EMAIL PROTECTED] writes: On Wed, Mar 13, 2002 at 02:12:18PM -0500, Jeff Trawick wrote: Jeff Trawick [EMAIL PROTECTED] writes: I think this is an accurate statement regarding the use of non-ASCII characters in filenames with Apache 1.3 on Win32. Comments? ---cut here-- Names of file-based resources with Apache 1.3 on Win32 Apache 1.3 on Win32 assumes that the names of files served are comprised solely of characters from the US-ASCII character set. It has no logic to determine whether or not a possible file name contains invalid non-ASCII characters. It has no logic to properly match actual non-ASCII file names with names specified in the Apache configuration file. Because Apache does not verify that the characters in file names are all ASCII, files files containing various non-ASCII characters in their names can be successfully served by Apache. However, this is not recommended for the following reasons: No, it doesn't. It treats all names as raw bytes, regardless of charset, but the filtering process of preventing some filesystem-specific magic characters from creating security holes on a server prevents the use of unfiltered 16-bit Unicode or similar wide character sets from being used directly. This is true in general for the Web -- wide character encodings are not allowed to appear in URI under any circumstances. Wrong. Unix may allow any filename character excepting a '\0', but Win32 does not. Win32 filenames cannot be treated as 'raw bytes'. Except that we have used utf-8 folding on -all- filename resources through APR in 2.0. Effectively, all APR Win32 API calls are made in Unicode, using utf-8 - unicode folding [strict, as opposed to Microsoft's preference for ignoring the security impact of accepting too-many-bytes sequences.] So no Unicode filename in 2.0 is unaccessible, but local code pages cannot be used, since they are ambiguous. Utf-8 is unambiguous, and therefore ideal for this application. To Roy's other comment on a case-insensitive directive, that doesn't work as long as different OS's and network layers perform local code page comparisons differently, canonicalization is the only way to know that the file you've open()ed or stat()ed matches a given file that may or may not be protected by our directives, including that case-sense flag buried in the Directory block, as suggested :-) A user recently observed in a bugs report that Microsoft has tacked on their favorite FEFF unicode prefix in all utf-8 text files [folded into utf-8, of course.] While it's BS and preferable to ignore it, I will likely get a patch in that skips those characters when parsing httpd.conf or .htaccess files. This assures that security applied to utf-8 files is good as well. The last remaining bit of the utf-8 exercise is to eliminate the last of the 'tolower() is a good enough comparison' and 'strcasecmp always works.' Even on unix, these fns are always expressed in local code pages, and we want these to always map to utf-8 comparison. Worse, we want them to map to system internal mappings, so that we are on the same page as the file system when it comes to case folding. In 1.3, we were not on the same page, the msvcrt treats the 0x80-0xff chars differently than the file system [another security related reason they are really unsupported.] I'd like that issue really closed up in 2.0. Canonicalization has helped a ton, but there is still a bit of ambiguity in them thar strings. Bill The solution is to use UTF-8 encoding for non-ASCII characters and not allow any access via wide character function calls. Thanks a bunch for your response. I'm more than a little unclear on this stuff. Regarding your key comment treats all file names as raw bytes, regardless of charset... I would agree with that for Unix, but on Win32, in an attempt to match the semantics of the native filesystem (case preserving but not case significant), Apache will perform case transformations on file names*. This, along with the filtering code to check for specific ASCII values, is why I claimed that it assumes ASCII. *see ap_os_canonical_filename(), which is used to generate r-filename -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [1.3 PATCH/QUESTION] Win32 ap_os_is_filename_valid()
Here is an update to my previous statement based on comments from Roy and Bill. (And Roy, I'm going to get my butt flamed anyway.) I'd like to stick it at the end of Using Apache With Microsoft Windows (http://httpd.apache.org/docs/windows.html), unless somebody can think of a better place. Names of file-based resources with Apache 1.3 on Win32 Apache 1.3 on Win32 assumes that the names of files served are comprised solely of characters from character sets which are a superset of ASCII, such as UTF-8 or ISO-8859-1. It has no logic to determine whether or not a possible file name contains invalid characters. It has no logic to properly match actual non-ASCII file names with names specified in the Apache configuration file. Because Apache does not verify that the characters in file names are all from a valid character set, files containing various invalid characters in their names can be successfully served by Apache. However, this is not recommended for the following reasons: 1) Because Apache is unable to properly match actual non-ASCII file names with names in the Apache configuration file, taking into account any case folding or other transformations handled by the operating system when looking up files or otherwise matching file names, directives in the Apache configuration file may or may not be in force, depending on how the HTTP client specifies the resource. This may be a security concern, depending on your configuration. 2) Because Apache assumes that file names are from a character set which is a superset of ASCII, some of the checks it makes when validating file names will flag certain non-ASCII characters as invalid. For example, Apache on Win32 will flag a file name containing the ASCII character '|' (0x7C) as invalid. This logic will flag any file name containing the byte 0x7C as invalid, even if that byte does not represent '|' in the local character set. There are other characters checked for as well. Because of these checks, even if there are no security issues in your configuration, many Unicode characters or other wide characters cannot be used. Because of the lack of proper support for non-ASCII characters in file names, it is recommended that administrators not attempt to use any non-ASCII characters in file names. Any other configuration is unsupported. Apache 2.0 introduces the UTF-8 convention to access any filenames and resources in a predictable and safe manner. The implementation of this feature is too extensive to consider backporting to Apache 1.3. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
[STATUS] (apache-1.3) Wed Mar 13 23:45:04 EST 2002
APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2002/03/01 23:35:27 $] Release: 1.3.24-dev: In development. Jim proposes to TR around Mar 04 or so because of the Solaris pthread mutex fix and other fixes. 1.3.23: Tagged Jan 21, 2002. 1.3.22: Tagged Oct 8, 2001. Announced Oct 12, 2001. 1.3.21: Not released. (Pulled for htdocs/manual config mismatch. t/r Oct 5, 2001) 1.3.20: Tagged and rolled May 15, 2001. Announced May 21, 2001. 1.3.19: Tagged and rolled Feb 26, 2001. Announced Mar 01, 2001. 1.3.18: Tagged and rolled Not released. (Pulled because of an incorrect unescaping fix. t/r Feb 19, 2001) 1.3.17: Tagged and rolled Jan 26, 2001. Announced Jan 29, 2001. 1.3.16: Not released. (Pulled because of vhosting bug. t/r Jan 20, 2001) 1.3.15: Not released. (Pulled due to CVS dumping core during the tagging when it reached src/os/win32/) 1.3.14: Tagged and Rolled Oct 10, 2000. Released/announced on the 13th. 1.3.13: Not released. (Pulled in the first minutes due to a Netware build bug) 1.3.12: Tagged and rolled Feb. 23, 2000. Released/announced on the 25th. 1.3.11: Tagged and rolled Jan. 19, 2000. Released/announced on the 21st. 1.3.10: Not released. (Pulled at last minute due to a build bug in the MPE port) 1.3.9: Tagged and rolled on Aug. 16. Released and announced on 19th. 1.3.8: Not released. 1.3.7: Not released. 1.3.6: Tagged and rolled on Mar. 22. Released and announced on 24th. 1.3.5: Not released. 1.3.4: Tagged and rolled on Jan. 9. Released on 11th, announced on 12th. 1.3.3: Tagged and rolled on Oct. 7. Released on 9th, announced on 10th. 1.3.2: Tagged and rolled on Sep. 21. Announced and released on 23rd. 1.3.1: Tagged and rolled on July 19. Announced and released. 1.3.0: Tagged and rolled on June 1. Announced and released on the 6th. 2.0 : In alpha development, see httpd-2.0 repository RELEASE SHOWSTOPPERS: RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * htpasswd.c and htdigest.c use tmpnam()... consider using mkstemp() when available. Message-ID: [EMAIL PROTECTED] Status: * Dean's unescaping hell (unescaping the various URI components at the right time and place, esp. unescaping the host name). Message-ID: [EMAIL PROTECTED] Status: * Martin observed a core dump because a ipaddr_chain struct contains a NULL-server pointer when being dereferenced by invoking httpd -S. Message-ID: [EMAIL PROTECTED] Status: Workaround enabled. Clean solution can come after 1.3.19 * long pathnames with many components and no AllowOverride None Workaround is to define Directory / with AllowOverride None, which is something all sites should do in any case. Status: Marc was looking at it. * Ronald Tschalär's patch to mod_proxy to allow other modules to set headers too (needed by mod_auth_digest) Message-ID: [EMAIL PROTECTED] Status: Available Patches (Most likely, will be ported to 2.0 as appropriate): * Support for daemontools (already in 2.0): http://www.apache.org/dist/httpd/contrib/patches/1.3/daemontools.patch Message-ID: [EMAIL PROTECTED] Status: * A rewrite of ap_unparse_uri_components() by Jeffrey W. Baker [EMAIL PROTECTED] to more fully close some segfault potential. Message-ID: Pine.LNX.4.21.0102102350060.6815-20@desktop Status: Jim +1 (for 1.3.19), Martin +0 * Patch from C. Bottelier [EMAIL PROTECTED] to run Apache without daemonizing the parent process. PR#7040 Status: fanf +1 (except it needs docs) * Andrew Ford's patch (1999/12/05) to add absolute times to mod_expires Message-ID: [EMAIL PROTECTED] Status: Martin +1, Jim +1, Ken +1 (on concept) * Raymond S Brand's path to mod_autoindex to fix the header/readme include processing so the envariables are correct for the included documents. (Actually, there are two variants in the patch message, for two different ways of doing it.) Message-ID: [EMAIL PROTECTED] Status: Martin +1(concept) * Jayaram's patch (10/27/99) for changes to mod_autoindex Problem 1: AddIcon (alttext,icon) ^^DIRECTORY^^ and AddIcon (alttext,icon) ^^BLANKICON^^ should be able to set the alternate text and icon file for any directory/blankicon in a directory listing. This was not happening because the alternate text for ^^DIRECTORY^^ and ^^BLANKICON^^ were hardcoded to DIR and respectively. Status: resolved in Apache 2.0 Problem 2: - IndexIgnore
[STATUS] (httpd-2.0) Wed Mar 13 23:45:06 EST 2002
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2002/03/12 14:41:29 $] Release: 2.0.34 : in development 2.0.33 : tagged March 6, 2002. 2.0.32 : released Feburary 16, 2002. 2.0.31 : rolled Feburary 1, 2002. not released. 2.0.30 : tagged January 8, 2002. not rolled. 2.0.29 : tagged November 27, 2001. not rolled. 2.0.28 : released November 13, 2001 2.0.27 : rolled November 6, 2001 2.0.26 : tagged October 16, 2001. not rolled. 2.0.25 : rolled August 29, 2001 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Please consult the following STATUS files for information on related projects: * srclib/apr/STATUS * srclib/apr-util/STATUS * docs/STATUS CURRENT RELEASE NOTES: * 34 status: Let's get all API changes and showstoppers in this one. Please. FINAL RELEASE SHOWSTOPPERS: * If any request gets to the core handler, without a flag that this r-filename was tested by dir/file_walk, we need to 500 at the very end of the ap_process_request_internal() processing. This provides authors of older modules better compatibility, while still improving the security and robustness of 2.0. Status: still need to decide where this goes, OtherBill comments... Message-ID: 065701c14526$495203b0$[EMAIL PROTECTED] we need to look at halting this in the 'default handler' case, and that implies pushing the 'handler election' into the request internal processing phase from the run request phase. Jim asks: would a stopgap be something bogus like adding another flag to request_rec ala eos_sent and before we OK, if not set force 500? Jeff says: reviewing the original message and the one follow-up (also from OtherBill) it looks like OtherBill had a good handle on the problem, though I wonder why not just put a simple check in default_handler to see if dir/file_walk has been done (a footprint left by dir/file_walk doesn't have to be in request_rec; a better place is core_request_config) * We need to find out the right place to add the AddOutputFilterByType directive. mod_mime? No. core with fixups? That's what it is now. ap_pass_brigade() hook? As a filter that runs at HTTP_HEADER stage? This needs to be resolved before the next public release. Message-ID: 018701c1b99c$f0f24310$0a01230a@KOJ * API changes planned for 2.0 that should happen before the GA release: * Free lists for bucket allocation * Pool allocator change * We do not properly substitute the prefix-variables in the configuration scripts or generated-configs. (i.e. if sysconfdir is etc, httpd-std.conf points to conf.) Aaron says: This is not a showstopper, these problems have existed for as long as I can remember. It would be nice to fix them but they are not new. * Address popular PRs * Win32 doesn't install as service correctly [9863, 9914, 9961] * Don't be stupid and cd to a blank directory when doing installs [PR 9993] CURRENT VOTES: * Should we always build binaries statically unless otherwise indicated? Message-ID: [EMAIL PROTECTED] +1: Ken -1: Justin, Ian * If the parent process dies, should the remaining child processes gracefully self-terminate. Or maybe we should make it a runtime option, or have a concept of 2 parent processes (one being a hot spare). See: Message-ID: [EMAIL PROTECTED] Self-destruct: Ken, Martin Not self-destruct: BrianP, Ian, Cliff, BillS Make it runtime configurable: Aaron, Jim, Justin Have 2 parents: +1: Jim -1: Justin +0: Martin (while standing by, could it do something useful?) * Make the worker MPM the default MPM for threaded Unix boxes. +1: Justin, Ian, Cliff -0: Aaron (premature decision, needs more discussion), Lars RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * mod_negotiation may be broken on
Re: [1.3 PATCH/QUESTION] Win32 ap_os_is_filename_valid()
Apache 1.3 on Win32 assumes that the names of files served are comprised solely of characters from character sets which are a superset of ASCII, such as UTF-8 or ISO-8859-1. Umm, I assume that ASCII as you refer to it is its 7-bit incarnation. Its 8-bit incarnation is referred to as US-ASCII, ANSI-X3.1968 (or some such), or more commonly ISO-8859-1 (also called latin-1). Note that _all_ character sets are supersets of 7-bit ASCII, and most are supersets of 8-bit ASCII (the exceptions being the various other 'latin' encodings - i.e. ISO-8859-2 through ISO-8859-16 which differ in the various 'special' characters). This has the lovely side-effect that English is always an option, regardless of the actual encoding being used. The difference is in the amount and position of the bytes. Wide character sets will pad to the left or right (depending on whether little-endian or big-endian order is in effect) with a null character. As well, various byte- order markers may be present (ffef, feff, etc). It has no logic to determine whether or not a possible file name contains invalid characters. It has no logic to properly match actual non-ASCII file names with names specified in the Apache configuration file. Because Apache does not verify that the characters in file names are all from a valid character set, files containing various invalid characters in their names can be successfully served by Apache. I think you've missed the boat on this one. Asian versions of Windows will all probably use characters that you don't consider as ASCII (i.e. they will be wide - actually Microsoft have done a pretty good job of this). I think what you meant to say was that only English (and, come to think of it, only English versions of Windows) is recommended - with wide character support promised in Apache 2.0. Regards
Re: [1.3 PATCH/QUESTION] Win32 ap_os_is_filename_valid()
At 12:29 AM 3/14/2002, you wrote: Apache 1.3 on Win32 assumes that the names of files served are comprised solely of characters from character sets which are a superset of ASCII, such as UTF-8 or ISO-8859-1. Umm, I assume that ASCII as you refer to it is its 7-bit incarnation. Note that _all_ character sets are supersets of 7-bit ASCII, and most are supersets of 8-bit ASCII (the exceptions being the various other 'latin' encodings - i.e. ISO-8859-2 through ISO-8859-16 which differ in the various 'special' characters). This has the lovely side-effect that English is always an option, regardless of the actual encoding being used. Uhmm... you are only partially correct. Yes - 7-bit ASCII exists in nearly all character sets unblemished, were it not for multibyte encodings. Some encodings are 7-bit clean, that is, their other characters do not map into 0x00-0x7F. Examples are utf-8 and most European encodings. Counterexamples, however, include many Asian sets including shift-JIS where the 0x00-0x7F alternate meanings between their ASCII encoding and shifted-state bytes. The user of the Chinese character set who first commented on this in bugs ran into exactly this problem in certain shifted character combinations. I think you've missed the boat on this one. Asian versions of Windows will all probably use characters that you don't consider as ASCII (i.e. they will be wide - actually Microsoft have done a pretty good job of this). No... Jeff didn't miss anything. Not only is this an issue with unclean 7-bit encodings, but the 8-bit encodings are not normalized correctly on Win32, and Win32 is case insensitive. Essentially, any Files or Directory blocks they use to protect file paths that include 8-bit characters don't even map correctly for Windows-1252 or OEM-437. Those are the sad but accurate facts. For tolower/toupper/strcasecmp, I will have a patch sometime this month to trust utf-8 and normalize appropriately, using the Win32 API which gives us some greater assurance that the mappings correspond to filename processing semantics. For 2.0, of course.
