Re: [PATCH] DeflateFilterNote extension
André Malo wrote:
This bubbled up on some discussion with statistic freaks:
The attached patch allows the user to log the accurate filter input and
output byte count, instead of only the rounded compression ratio.
The DeflateFilterNote directive will be extended as follows:
DeflateFilterNote [type] name
type can be one of input, output or ratio. ratio is assumed if the
type is omitted (backwards compatible).
Example:
DeflateFilterNote input deflate-in
DeflateFilterNote output deflate-out
LogFormat '%t %r %{deflate-in}n/%{deflate-out}n' deflate
Great !!!
Re: [PATCH] mod_deflate extensions
I also refer you to the discussion thread regarding the original inclusion of mod_deflate which contains some 'advice' posted to the Apache forum from Dr. Mark Adler ( one of the original authors of all this GZIP/ZLIB LZ77 code ). He suggested that compiling your OWN version of GZIP/ZLIB was pretty much the only 'sane' thing to do and I agree 100%. There are actually a number of 'flaky' distributions of GZIP/ZLIB 'out there'. He ( Mark Adler ) himself pointed out that there are some 'patches' floating around for GZIP/ZLIB that never made it into ANY standard distribution and only by applying them yourself to your own compiled OBJ/LIB could you be sure what you are actually using and what shape it is in. So we should use a copy of mod_gzip compression code in Apache 2.0. Also as someone involved in mod_jk/jk2, I'll need gzip compress/uncompress support in Apache 2.0 for a new ajp protocol I'm working on, so having compression/uncompression in Apache 2.0 will be mandatory for me. If they REALLY WANT some 'feature' in their Server... they will tough it out and get it done. That's the way it's always been with Apache so no one would be shocked if some LIB wasn't in the right place or a makefile needed tweaking. Ok, let be pragmatic. Did Apache HTTP developpers agree that compression should be added in Apache 2.0 by incorporating mod_gzip comp code in Apache 2.0 ?
Re: cvs commit: httpd-2.0/server listen.c
On 14 Nov 2002 14:17:11 -, [EMAIL PROTECTED] wrote:
trawick 2002/11/14 06:17:11
Modified:.CHANGES acinclude.m4 configure.in
docs/conf httpd-std.conf.in ssl-std.conf
server listen.c
Log:
Add --[enable|disable]-v4-mapped configure option to control
whether or not Apache expects to handle IPv4 connections
on IPv6 listening sockets. Either setting will work on
systems with the IPV6_V6ONLY socket option. --enable-v4-mapped
must be used on systems that always allow IPv4 connections on
IPv6 listening sockets.
after this commit, httpd cannot run with following error;
[Fri Nov 22 20:01:43 2002] [crit] (22)Invalid argument: make_sock: for address
127.0.0.1:80, apr_socket_opt_set: (IPV6_V6ONLY)
no listening sockets available, shutting down
Unable to open logs
on my FreeBSD boxes, both -current and -stable with ipv4-mapping
disabled and enabled respectively.
i think this error occurs because IPV6_V6ONLY option are being set
on all sockets; even if on the IPv4 sockets.
following is a patch to set IPV6_V6ONLY option on only IPv6 sockets.
i don't know if this is a correct answer but it solves at least my problem...
Regards,
hiro hanai
-
Index: listen.c
===
RCS file: /fs/pub/cvs/Apache/httpd-2.0/server/listen.c,v
retrieving revision 1.83
diff -u -r1.83 listen.c
--- listen.c14 Nov 2002 14:17:11 - 1.83
+++ listen.c22 Nov 2002 09:52:45 -
@@ -118,14 +118,16 @@
}
#if APR_HAVE_IPV6
-stat = apr_socket_opt_set(s, APR_IPV6_V6ONLY, v6only_setting);
-if (stat != APR_SUCCESS stat != APR_ENOTIMPL) {
+if (server-bind_addr-family == AF_INET6) {
+ stat = apr_socket_opt_set(s, APR_IPV6_V6ONLY, v6only_setting);
+ if (stat != APR_SUCCESS stat != APR_ENOTIMPL) {
ap_log_perror(APLOG_MARK, APLOG_CRIT, stat, p,
make_sock: for address %pI, apr_socket_opt_set:
(IPV6_V6ONLY),
server-bind_addr);
apr_socket_close(s);
return stat;
+ }
}
#endif
-
Re: cvs commit: httpd-2.0/server listen.c
hiroyuki hanai [EMAIL PROTECTED] writes: On 14 Nov 2002 14:17:11 -, [EMAIL PROTECTED] wrote: trawick 2002/11/14 06:17:11 Modified:.CHANGES acinclude.m4 configure.in docs/conf httpd-std.conf.in ssl-std.conf server listen.c Log: Add --[enable|disable]-v4-mapped configure option to control whether or not Apache expects to handle IPv4 connections on IPv6 listening sockets. Either setting will work on systems with the IPV6_V6ONLY socket option. --enable-v4-mapped must be used on systems that always allow IPv4 connections on IPv6 listening sockets. after this commit, httpd cannot run with following error; [Fri Nov 22 20:01:43 2002] [crit] (22)Invalid argument: make_sock: for address 127.0.0.1:80, apr_socket_opt_set: (IPV6_V6ONLY) no listening sockets available, shutting down Unable to open logs on my FreeBSD boxes, both -current and -stable with ipv4-mapping disabled and enabled respectively. i think this error occurs because IPV6_V6ONLY option are being set on all sockets; even if on the IPv4 sockets. following is a patch to set IPV6_V6ONLY option on only IPv6 sockets. i don't know if this is a correct answer but it solves at least my problem... Yes, this is so obviously a necessary change (blush). I had so much trouble with the config-time changes to generate the right httpd.conf that I guess my brain was fried when coming up with test variations for the actual code :( Regards, hiro hanai Thanks so much! I expect to commit shortly, after which the beatings will resume. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/include ap_release.h
[EMAIL PROTECTED] writes: wrowe 2002/11/21 18:08:42 Modified:include ap_release.h Log: Branch tag APACHE_2_0_BRANCH now contains Apache 2.0 development. Persist cvs HEAD as Apache 2.1. After discussion at AC, a number of individuals including Sander, Will, Justin and Rich will begin reverting the appropriate changes from the APACHE_2_0_BRANCH, while continuing their documentation and development of the Authorization reorganization on this branch. Does reverting the appropriate changes mean decide which stuff now tagged APACHE_2_0_BRANCH should be deferred until 2.1 or does it mean as fixes are committed to HEAD, decide which of them should be available in Apache 2.0 or does it mean something else? Shall I start a section in STATUS for votes on whether to move various fixes in HEAD back to APACHE_2_0_BRANCH? hiroyuki hanai's fix to listen.c would be the first candidate AFAICT. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
r-server-port = 80 = ap_default_port on a request to port 8095
Hi, I will try to draw the problem i got today with r-server-port I am in reverse proxy with apache 2.0 (cvs last checkout) i have UseCanonicalName Off I am behing a INTEL SSL Accelerator which connect on my apache reverse proxy on port 8095 but it never put in the request the port 8095 so apache receive GET /lala.html HTTP/1.1 Host: lala.com my vhost is: NameVirtualHost ip:8095 virtualhost ip:8095 servername lala.com /virtualhost When my module is checking the server-port, it find 80 instead of 8095 When i setup UseCanonicalName On, my module find the 8095 in server-port. when i read the server/core.c i find: for UseCannonicalName Off: port = r-parsed_uri.port ? r-parsed_uri.port : r-server-port ? r-server-port : ap_default_port(r); can somebody could explain me why it's not trying the r-connection-local_addr-port like: port = r-parsed_uri.port ? r-parsed_uri.port : r-server-port ? r-server-port : r-connection-local_addr-port ? r-connection-local_addr-port : ap_default_port(r); before sending the default port. I think it's for special case but i would like to know which one. I am now using directly r-connection-local_addr-port in my module so it's working fine. regards, Estrade Matthieu __ Modem offert : 150,92 euros remboursés sur le Pack eXtense de Wanadoo ! Haut débit à partir de 30 euros/mois : http://www.ifrance.com/_reloc/w
Re: 2.0, 2.1 branch, WAS: Re: Renames
At 03:09 PM 11/20/2002, Sander Striker wrote: Jeff Trawick wrote: Thom May [EMAIL PROTECTED] writes: So what is the consensus with the renames? The patch is available from http://cvs.apache.org/~thommay/full-rename-diff and seems good - it builds and passes tests on (at least) BeOS and OS X. Also, httpd and svn don't need any changes to still work - the functions are all wrapped by the old names. So it's just binary compatibility that's the problem. But binary incompatibility breaks the notion of a stable httpd API. Can we hold off until Sander tags everything for an httpd release? (I guess Sander is still planning to tag.) Always useful if Sander responds ;) Bottom line: I'm not going to tag before we branch. It all comes down to this: - The auth changes _don't_ break 3rd party auth modules - We can rename the auth modules and their directives back to their old names so we don't break existing 2.0 configs - We must add implicit loading of mod_auth_basic when no auth provider was loaded - AFAIK the renames don't break bin compat, everything is wrapped in stubs So, we're ok. We can branch right now, because the state of the tree today is probable what we want to use as the basis for 2.1/2.2. Once we get the auth stuff renamed and the implicit loading in place I'll tag 2.0.44. My guess is that this will probably happen next week somewhere. Justin? Jeff, OtherBill, does httpd-2.0 HEAD contain anything you'd rather not see rolled into 2.0.44 (apart from the above)? Diff'ing 2.0.43 include/ I don't see any changes externally that would affect any third party modules, except the most obscure. It's probably best to simply pound on the code through the usual regressions (I'm attempting to create ISAPI regressions from the MSDN samples, provided a Win32 user has the MSDN installed and patched to fix MS's bugs in their ISAPI samples.) I'll collect that patch and those tests (my first attempt to build any new stuff in perl-framework) and run those regressions this weekend. And if I can find the right solution to fix the SSL HTTP over HTTPS error result regression we should get that back to HTTP/1.0 for release 2.0.44. Bill Bill
Re: mod_usertrack patch
+1 on committing this. I finally got around to testing it. -Rasmus On Thu, 7 Nov 2002, Andrei Zmievski wrote: Hello, I am submitting a patch to mod_usertrack for your consideration. This patch was developed here at Fast Search Transfer for alltheweb.com and provides the following changes: - ability to have a verbose and a compact version of the cookie - ability to set a prefix string for the cookie This patch is meant for 1.3.x versions. Please copy me on the replies. Regards, -Andrei
Re: [Patch] Be more selective on includes
At 07:58 PM 11/20/2002, Thom May wrote: This is in response to a debian bug request; basically it just tightens up the list of allowed characters, so we don't include .dotfiles and backups etc. Thoughts? Yea... I'd ask for exactly what I've been asking for over a year... ...does anyone have a decent reference to the exclusion applied for other packages that provide the config directory globbing that we added/emulated with this feature? Can we be consistent for the benefit of the administrator community here? Bill
Re: [STATUS] (apache-1.3) long pathnames with many components
At 12:04 AM 11/21/2002, Glenn wrote:
And now a question about the code: why bother checking for .htaccess files
outside of valid DocumentRoots (or UserDirs)? If you need to set directives
above the document root, create a Directory block in httpd.conf.
Apache checks whatever you ask it to. If your config includes the
AllowOverrides none at the Directory / layer, and AllowOverrides x
at the Directory {docroot} layer, it does exactly what you want.
One server's docroot may be simply a node within another vhost.
Also for Apache 3.0, can AllowOverride None be the default?
It is a more secure default, besides providing better performance.
Just as I said. You actually decrease security if the administrator
has populated .htaccess files and you flip the default on them.
I'm not against a commented out AllowOverrides None within the
default Directory / block, explaining it's behavior and why one
would enable that directive. Feel free to offer such a patch to
the httpd-std.conf files.
Bill
Re: [PATCH] IndexResults for mod_autoindex
Francis, very cool patch! I'll look at it if noone beats me to it,
you aren't the only one who wants this feature :-)
Bill
At 03:09 AM 11/21/2002, Francis Daly wrote:
Hi there,
This is a late follow-on from some posts in May.
mod_autoindex in Apache/2 does not show filenames for which the requester is
not authenticated, which is a change from the 1.3 behaviour.
The first patch below introduces a per-directory directive which
allows the administrator list which http statuses (or status groups)
should be shown or hidden.
When left unset, I found no clear performance difference in listing a
directory where no authentication was required (as expected); and also
found no clear performance difference in listing a directory where each
file individually required authentication (which was a bit of a
surprise to me).
Built and tested against vanilla 2.0.43, it applies cleanly to the
current CVS version, 1.111.
The second patch below is a docs patch against mod_autoindex.xml 1.12.
There are two further optional code patches to follow, which are only
useful if something similar to these are accepted.
Any comments (and further performance testing) welcome.
f
--
Francis Daly[EMAIL PROTECTED]
--- modules/generators/mod_autoindex.c 17 Oct 2002 18:09:52 -
+++ modules/generators/mod_autoindex.c 21 Nov 2002 02:33:31 -
@@ -154,6 +154,12 @@
int wildcards;
} ai_desc_t;
+/* res_info is used when merging res_list */
+typedef struct res_info {
+int *range;
+apr_table_t *tab;
+} res_info;
+
typedef struct autoindex_config_struct {
char *default_icon;
@@ -175,6 +181,7 @@
apr_array_header_t *ign_list;
apr_array_header_t *hdr_list;
apr_array_header_t *rdme_list;
+apr_table_t *res_list;
} autoindex_config_rec;
@@ -320,6 +327,45 @@
return NULL;
}
+static const char *set_results(cmd_parms *cmd, void *d, const char *name)
+{
+char entry[4];
+int showp = 1;
+
+if (name[0] == '-') {
+showp = 0;
+name++;
+}
+
+/* verify that the form is valid */
+if (name[0] == '\0' || name[1] == '\0' || name[2] == '\0' ||
+name[3] != '\0') {
+return Value (after leading minus) must be three characters long;
+}
+
+/* verify that the value is valid */
+if ((name[0] '1' || name[0] '9')
+|| !((isdigit(name[1]) isdigit(name[2]))
+|| (name[1] == 'x' name[2] == 'x'))) {
+return Value must be [-]### or [-]#xx, where # is a digit;
+}
+
+strcpy(entry, name);
+if (name[1] == 'x') {
+entry[1] = '\0';
+}
+
+/* The value here is a string beginning with 1 (for show) or
+ * a string not beginning with 1 (for hide), as per show_result() */
+if (showp) {
+apr_table_set(((autoindex_config_rec *) d)-res_list, entry, 1);
+} else {
+apr_table_set(((autoindex_config_rec *) d)-res_list, entry, 0);
+}
+
+return NULL;
+}
+
static const char *add_ignore(cmd_parms *cmd, void *d, const char *ext)
{
push_item(((autoindex_config_rec *) d)-ign_list, 0, ext, cmd-path, NULL);
@@ -578,6 +624,8 @@
one or more file extensions),
AP_INIT_ITERATE2(AddDescription, add_desc, BY_PATH, DIR_CMD_PERMS,
Descriptive text followed by one or more filenames),
+AP_INIT_ITERATE(IndexResults, set_results, NULL, DIR_CMD_PERMS,
+one or more http status codes),
AP_INIT_TAKE1(HeaderName, add_header, NULL, DIR_CMD_PERMS,
a filename),
AP_INIT_TAKE1(ReadmeName, add_readme, NULL, DIR_CMD_PERMS,
@@ -590,7 +638,7 @@
{NULL}
};
-static void *create_autoindex_config(apr_pool_t *p, char *dummy)
+static void *create_autoindex_config(apr_pool_t *p, char *dir)
{
autoindex_config_rec *new =
(autoindex_config_rec *) apr_pcalloc(p, sizeof(autoindex_config_rec));
@@ -607,15 +655,47 @@
new-ign_list = apr_array_make(p, 4, sizeof(struct item));
new-hdr_list = apr_array_make(p, 4, sizeof(struct item));
new-rdme_list = apr_array_make(p, 4, sizeof(struct item));
+new-res_list = apr_table_make(p, 4);
new-opts = 0;
new-incremented_opts = 0;
new-decremented_opts = 0;
new-default_keyid = '\0';
new-default_direction = '\0';
+/* include, effectively, a global IndexResults 3xx */
+if (dir == NULL) {
+apr_table_set(new-res_list, 3, 1);
+}
+
return (void *) new;
}
+static int res_list_ranges(int *range, const char *key, const char *dummy)
+{
+int ikey;
+
+ikey = atoi(key);
+if (ikey 10) {
+range[ikey] = 1;
+range[0] = 1;
+}
+return 1;
+}
+
+static int res_list_del_entries(res_info *info, const char *key,
+const char *dummy)
+{
+int ikey;
+
+ikey = atoi(key);
+if (ikey = 100) {
+if ((*info).range[ikey/100] == 1) {
+apr_table_unset((*info).tab, key);
+}
+}
+return 1;
+}
+
static
Re: [PATCH] mod_deflate extensions
At 09:58 AM 11/21/2002, Henri Gomez wrote: So what about for 2.0.45 dev ? My prediction about interest in such a switch was independent of timeframe. I doubt that such a switch will ever happen. 2.0.44 won't be the last 2.0 release isn't it ? No... 2.0.45 will be compatible with 2.0.44 modules, if and when a significant number of bugfixes or a security hole is patched. 2.0.x will simply remain compatible with 2.0.42 forward. Authors may choose not to backport new features to 2.0, or they may do so, it's up to them. What do you means ? - Put zlib full source tree in Apache 2.0 tree and make a static build ? not all of zlib is necessary... and if we build zlib as a library (instead of pulling specific objects into mod_deflate.so) we have portability problems to deal with... We could grab the compression part, like does mod_gzip, mod_gzip even use zlib includes. Actually, we do need decompression in some cases (which was subject to the security hole suffered with earlier zlib versions). Proxy might be one such example. Another would be ungzipping cached content based on the client accept-encoding details. - Put part of zlib code in Apache 2.0 source ? that is what I suspect to be the safest, easiest-to-understand way... the build would work like on Windows, where the project file for mod_deflate pulls in the right parts when building mod_deflate.so Ok That is an interesting concept - I actually just took the time to get zlib building on win32 with a parallel configure.pl script. I'll post that fun at some point. The biggest PITA on Win32 was the choice of compiling against static c libraries instead of msvcrt which Apache lives with. Building in some static clib while leaving others dynamic just seemed evil to me, so none of the win32 library-build examples work out of the box to give you msvcrt linkage. My playing with a configure.pl script was just another means to that same end. another nice feature of this is that if we know we are using our build of the zlib source then we can turn on the zlib compile option to namespace-protect the zlib routines and then change mod_deflate to assume that (but perhaps the compile switch will make mod_deflate use the namespace-protected versions automatically anyway)... OtherBill mentioned this namespace protection before but I haven't had a chance to play with it Or what about adding zlib compression in APR project, which is more system related and use it ? The APR 0.9 branch is still open ? Good idea. The point is that we can always add to a branch for a future release as long as we aren't breaking compatibility. I already saw a user having problems because a shared library used by a 3rd party module also had a routine called crc32(). Yes, and I've encountered problem with mod_gzip because one the PHP module was linked against ct_lib ;) Such a hassle, yes. - or make configure detect zlib shared lib and make mod_deflate available by default ? if this can be made foolproof then this is perhaps a good option too... but I'm not sure that is portable on whether the DSO needs to be linked with zlib or whether httpd needs to be linked with zlib... and if httpd needs to be linked with zlib then the export file generation needs to do the right thing... IIRC, one solution that would work fine on Linux and Solaris and FreeBSD wouldn't work on HP-UX (I might have the platforms listed in the wrong place; maybe AIX was one of the platforms)... So extracting zlib source part and include them in Apache or APR seems to be the best solution.
Re: cvs commit: httpd-2.0/include ap_release.h
At 06:50 AM 11/22/2002, Jeff Trawick wrote: [EMAIL PROTECTED] writes: wrowe 2002/11/21 18:08:42 Modified:include ap_release.h Log: Branch tag APACHE_2_0_BRANCH now contains Apache 2.0 development. Persist cvs HEAD as Apache 2.1. After discussion at AC, a number of individuals including Sander, Will, Justin and Rich will begin reverting the appropriate changes from the APACHE_2_0_BRANCH, while continuing their documentation and development of the Authorization reorganization on this branch. Does reverting the appropriate changes mean decide which stuff now tagged APACHE_2_0_BRANCH should be deferred until 2.1 or does it mean as fixes are committed to HEAD, decide which of them should be available in Apache 2.0 or does it mean something else? No. After Sander's comments, APACHE_2_0_BRANCH is now from CVS head. We can selectively revert those changes that break compatibility, introduce potential buggyness, or simply aren't complete. One of the HUGEST hassles is the effort to choose month-old patches to backport into 2.0. This was barely on folks' radar. Now that it's done, we can all be alert to those patches we are committing that we also want to backport. I don't want to see maintenance die on the 2.0 branch, and as Sander pointed out, most of the patches this last month were 'goodness'(sm). Bill Shall I start a section in STATUS for votes on whether to move various fixes in HEAD back to APACHE_2_0_BRANCH? hiroyuki hanai's fix to listen.c would be the first candidate AFAICT. Since we split at 2002/11/21 18:08:42, please start taking names and kicking ass to previous patches that don't belong on the 2.0 branch. And looking forward, please remember that the 2_0_BRANCH is CTR, so you should commit to CVS HEAD and then ask for a vote, or take a vote on applying to both branches (simply mention you want the patch applied to both 2.0 and 2.1.) If it's voted on first, we will apply to both when it's committed. Bill
