Re: DAV and lazy evaluation
At 12:11 PM 3/24/2007, Justin Erenkrantz wrote: I don't want to propose a bunch of tiny changes like this, but I'm looking towards a possible review of mod_dav. Meanwhile, anyone BTDT and have insights to share? What is BTDT? -- justin Been There, Done That
Re: 3.0 - Proposed Requirements
At 08:33 AM 2/14/2007, Garrett Rooney wrote: On 2/14/07, Paul Querna <[EMAIL PROTECTED]> wrote: This proposed list of requirements for a 3.0 platform. this list enables a 'base' level of performance and design decisions to be made. If others can make designs work with 'lessor' requirements, all the better, but I'm not worried about it. Proposed Requirements: - C99 Compiler. Are there any C99 compilers? I was under the impression that GCC was close, but nobody else really seemed to be pushing for it (i.e. Microsoft doesn't seem to care). According to all the information I've found, the only C99 features that Visual Studio 2005 supports are "long long", variadic macros, and C++ style comments (which they've supported for years because of requests from C++ customers).
Re: Win x64 build targets?
At 07:56 AM 11/2/2006, Ivan Ristic wrote: BTW, what's a "round tuit"? :) It's a play on words: "I'll do it when I get around to it" -> "I'll do it when I get a round tuit" If you don't have enough round tuits, you don't have the time to do something.
Re: svn commit: r468373 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_cache.c modules/cache/mod_cache.h modules/cache/mod_disk_cache.c modules/cache/mod_disk_cache.h modules/cache/mo
At 01:41 PM 10/27/2006, Davi Arnaut wrote: Niklas Edmundsson wrote: > And when you have a file backend, you want to hit your disk cache and > not the backend when delivering data to a client. People might think > that this doesn't matter, but for large files, especially larger than > RAM in your machine, you usually go disk-bound without much help from > the OS disk cache. But that's a corner case. There is no reason in doing this for small files (common case). For example, in a enterprise grade server memory is cheap and permanent storage is slow and expensive. So why would this server be using mod_disk_cache in that case? Shouldn't this server be using mod_mem_cache? Selecting mod_disk_cache over mod_mem_cache means it's better to serve the cache from disk rather than from memory. If serving from the disk on the original request is too slow, then wouldn't serving from the disk on the subsequent requests be too slow as well?
Re: [PATCH] Support for external listener
At 10:39 AM 3/20/2006, Sander Temme wrote: On Mar 20, 2006, at 12:26 AM, Graham Leggett wrote: Sander Temme wrote: What do you, the httpd dev community, think of: 1) the concept? This kind of thing is definitely overdue - tomcat has had this for ages. 2) the attached implementation? Tomcat lets you override the address as well, although I guess this would be covered by the use of ServerName and ServerAlias. Yes, I expect to handle that part of the problem with the existing directive. Isn't the port already handled by existing directives?
Re: Code update to handle apache dynamic configuration updates to httpd.conf.
Prathama first wrote: But my requirement is that I shouln't restart the apache web server while updating the certificates. As there are many other requests to other virtual hosts are being processed. Prathama then wrote: But the requirement for my project itself is to be able to update the configuration (update SSL certificates/key of a virtual host) dynamically without restart. I think if you reworded your requirements a bit, then you would have a better chance at finding a solution that will work for you. "My requirement is that I update the certificate without losing the many other requests to other virtual hosts that are being processed."
Re: macro facility/default conf file/auth groups
At 12:52 PM 8/4/2005, Paul A Houle wrote: (2) This particular system has a production and a test instance, so I'd love to have a way to set variables that I can interpolate into arbitrary strings. For instance, everything connected with the production system may be under This already exists in mod_macro (google knows where it is).
Re: mod_smtpd design.
At 11:34 AM 7/1/2005, Rian A Hunter wrote:
Quoting Garrett Rooney <[EMAIL PROTECTED]>:
> Rian Hunter wrote:
> > type misc_smtp_handler(request_rec *r) {
> > smtpd_request_rec *smtp_data;
> >
> > if (strncmp("http", r->protocol_name, 4)) {
> > // decline to handle, this module doesn't handle
> > // http requests.
> > }
> > //then get smtpd specific data
> > smtp_data = get_smtpd_request(r);
> >
> > // do some handlin'
> > }
> >
> > The advantage to this approach is a less bulky (but more all
> > encompassing) request_rec with support for an arbitrary amount
of
> > protocols and protocol specific data.
>
> Rather than inserting dozens of strcmps all throught the
processing, I'd
> prefer to store an int identifying the protocol, and just have a
simple
> compare. No reason to burn CPU on the strcmp if we don't have to.
>
> -garrett
>
The reason I suggested a strcmp is that it gives freedom to module
developers to
set and implement any protocol they like. Doing integer comparisons
would
require us to maintain a list of "official" integer->protocol
mappings, but
there may be other ways to approach it without having that
constraint. Maybe we
can use the official iana port description list to specifiy
protocols like 80
means http, 25 means smtp, 143 means imap etc.
It doesn't need to be a compile-time mapping. There could be a
per-process mapping from string to integer. On load, each module
calls a function to register the protocols that they're interested
in. If the protocol has already been registered, its integer is
returned. If not, it is given the next slot in the protocol table,
and the new integer is returned.
Re: HTTPD 2.1 (Head) Build issues for NetWare...
At 10:42 AM 6/17/2005, William A. Rowe, Jr. wrote: Checkout date/time is generally the right choice for developers, because otherwise make doesn't always pick up when a file has changed. (I've been bit by the Visual SourceSafe "modification time" default enough times.) Although - heh - you are assuming the order of the checked out files happen to be stacked so that the dependency happens to be a fraction of a second older than the target :) Actually, I'm assuming that there are no checked in files that are dependents of other checked in files, (no generated files ever checked in) since that's also asking for trouble (been there, done that).
Re: HTTPD 2.1 (Head) Build issues for NetWare...
At 12:01 PM 6/16/2005, William A. Rowe, Jr. wrote: Back to httpd land; the question is --- is this the right choice for *our tarballs*? Which may or may not be related to the question above. In any case; this is useful metadata even for end users who build the package for the reasons I mentioned; does anyone have a desire/justification to lose the commit dates and use the RM's checkout date? It seems to me that modification or commit date/time is the right choice for *tarballs*. Checkout date/time is generally the right choice for developers, because otherwise make doesn't always pick up when a file has changed. (I've been bit by the Visual SourceSafe "modification time" default enough times.)
Re: do we still want sendfile enabled with our default conf files?
At 11:23 AM 3/18/2005, Justin Erenkrantz wrote: I absolutely refuse to punish users who are using good OSes because some OSes are brain-dead. This is exactly the role that APR is meant to fill Feel free to advocate Linux always returning APR_ENOTIMPL for sendfile - I don't care. However, blocking sendfile on non-buggy OSes is not a solution that I am willing to sign off on. -- justin Isn't this about a change to not enable sendfile in the default HTTPd config, not a change to APR to disable sendfile? In that case, this won't affect existing HTTPd users, because they already have it enabled in their config, and the default config never replaces an existing config.
Re: [OT] Developer lists and Reply-To header
At 07:20 AM 9/23/2004, Mladen Turk wrote: Is there any reason why apr, apr-util, httpd mailing lists have Reply-To header set to the sender and not to the list itself. I think almost all other lists has the 'Replay-To' header set to the list itself. I mean, I'm receiving the messages from the list and not from the particular poster, so I should reply to the list, right? Search for reply-to considered harmful on Google and you'll find more information than you ever wanted to read about both sides of the issue. I found myself couple of times replying to the original sender by default, while my intention was to reply to the list. The solution is either to 'reply to all' (why would anyone wish to receive two messages about the same subject?) or doing that by hand. The big question is which is worse, sending a message to the list when your intention was to send it to a single person, sending a message to a single person when your intention was to send it to the list. You'll find large numbers of people on each side. Some mailing list software is smart enough to not send an extra copy to members that will be receiving it directly.
Re: [PATCH] Re: Seg fault: race conditions in mod_mem_cache.c
At 06:53 PM 9/10/2004, Jean-Jacques Clar wrote:
I replaced the cleanup field with a bit set in refcount. This is
done to prevent race conditions when refcount is accessed on two
different threads/CPUS.
+#define OBJECT_CLEANUP_BIT 0x00F0
0x00F0 isn't a bit, it's 4 bits: 0x0010 | 0x0020 |
0x0040 | 0x0080
Why would you not use something farther up, such as 0x4000, for
the bit? (I imagine 0x8000 would cause problems if apr_atomic_t
isn't unsigned).
+
/* Forward declarations */
static int remove_entity(cache_handle_t *h);
static apr_status_t store_headers(cache_handle_t *h, request_rec
*r, cache_info *i);
@@ -152,17 +154,15 @@
{
cache_object_t *obj = (cache_object_t *)a;
-/* Cleanup the cache object. Object should be removed from the
cache
- * now. Increment the refcount before setting cleanup to avoid
a race
- * condition. A similar pattern is used in remove_url()
- */
-apr_atomic_inc(&obj->refcount);
-
-obj->cleanup = 1;
-
-if (!apr_atomic_dec(&obj->refcount)) {
+apr_atomic_t tmp_refcount = obj->refcount;
+/* Cleanup the cache object. Object should be removed from the
cache now. */
+if (!apr_atomic_read(&obj->refcount)) {
cleanup_cache_object(obj);
}
+else if(tmp_refcount != apr_atomic_cas(&obj->refcount,
tmp_refcount | OBJECT_CLEANUP_BIT, tmp_refcount)) {
+memcache_cache_free(obj);
+}
+return;
}
/*
* functions return a 'negative' score since priority queues
@@ -276,11 +276,11 @@
}
/* Remember, objects marked for cleanup are, by design,
already
* removed from the cache. remove_url() could have already
- * removed the object from the cache (and set obj->cleanup)
+ * removed the object from the cache (and set the
OBJECT_CLEANUP_BIT)
*/
-if (!obj->cleanup) {
+if (!(apr_atomic_read(&obj->refcount) &
OBJECT_CLEANUP_BIT)) {
cache_remove(sconf->cache_cache, obj);
-obj->cleanup = 1;
+apr_atomic_set(&obj->refcount, obj->refcount |
OBJECT_CLEANUP_BIT);
}
if (sconf->lock) {
apr_thread_mutex_unlock(sconf->lock);
@@ -288,10 +288,8 @@
}
/* Cleanup the cache object */
-if (!apr_atomic_dec(&obj->refcount)) {
-if (obj->cleanup) {
-cleanup_cache_object(obj);
-}
+if(apr_atomic_dec(&obj->refcount) == OBJECT_CLEANUP_BIT) {
+cleanup_cache_object(obj);
}
return APR_SUCCESS;
}
@@ -314,11 +312,7 @@
while (obj) {
/* Iterate over the cache and clean up each entry */
/* Free the object if the recount == 0 */
-apr_atomic_inc(&obj->refcount);
-obj->cleanup = 1;
-if (!apr_atomic_dec(&obj->refcount)) {
-cleanup_cache_object(obj);
-}
+memcache_cache_free(obj);
obj = cache_pop(co->cache_cache);
}
@@ -415,7 +409,6 @@
apr_atomic_set(&obj->refcount, 1);
mobj->total_refs = 1;
obj->complete = 0;
-obj->cleanup = 0;
obj->vobj = mobj;
/* Safe cast: We tested < sconf->max_cache_object_size above */
mobj->m_len = (apr_size_t)len;
@@ -536,9 +529,9 @@
* an object marked for cleanup is by design not in the
* hash table.
*/
-if (!obj->cleanup) {
+if (!(obj->refcount & OBJECT_CLEANUP_BIT)) {
cache_remove(sconf->cache_cache, obj);
-obj->cleanup = 1;
+apr_atomic_set(&obj->refcount, obj->refcount |
OBJECT_CLEANUP_BIT);
ap_log_error(APLOG_MARK, APLOG_INFO, 0, NULL, "gcing a
cache entry");
}
@@ -629,20 +622,13 @@
mem_cache_object_t *mobj;
cache_remove(sconf->cache_cache, obj);
mobj = (mem_cache_object_t *) obj->vobj;
-
-/* Refcount increment in this case MUST be made under
- * protection of the lock
- */
-apr_atomic_inc(&obj->refcount);
-if (obj) {
-obj->cleanup = 1;
-}
+apr_atomic_set(&obj->refcount, obj->refcount |
OBJECT_CLEANUP_BIT);
}
if (sconf->lock) {
apr_thread_mutex_unlock(sconf->lock);
}
if (obj) {
-if (!apr_atomic_dec(&obj->refcount)) {
+if(apr_atomic_read(&obj->refcount) == OBJECT_CLEANUP_BIT) {
cleanup_cache_object(obj);
}
}
@@ -908,8 +894,8 @@
if (sconf->lock) {
apr_thread_mutex_lock(sconf->lock);
}
-if (obj->cleanup) {
-/* If obj->cleanup is set, the object has been
prematurly
+if ((apr_atomic_read(&obj->refcount) &
OBJECT_CLEANUP_BIT)) {
+/* If OBJECT_CLEANUP_BIT is set, the object has
been prematurly
* ejected from the cache by the garbage
collector. Add the
* object back to the cache. If an object with
the same key is
* found in the cache, eject it in favor of
the comp
Re: Move apache-1.3 to Subversion
At 10:50 PM 7/15/2004, William A. Rowe, Jr. wrote: I agree, here, with Joe. Wondering if it's an appropriate alternative. I'm facing similar, with a subproject entering incubation, and I'd like to know our decision here, before I go and create a subproject structure under /httpd/ that turns out to be wonky. is /trunk/httpd/ an appropriate solution? This bit me, trying to check out some /incubation/ stuff. Everything I've seen on source control strategies recommends stuff like: /httpd/trunk/ /httpd/branches/ etc. This seems to make the most sense to me from an organizational standpoint, especially once you start adding other top level projects. As an example: /apr/trunk/ /apr-util/trunk/ /httpd/trunk/ makes a heck of a lot more sense than /trunk/httpd/ /trunk/apr/ /trunk/apr-util/ since the logical grouping is by project, then by whether it's the trunk or a branch, and then by the name of the branch. Someone that doesn't know the organization of the source may make this mistake once, if it's not well documented, or if they don't read the docs first. After that, they'll probably never make that mistake again. With the other direction, you'll constantly have to deal with the illogical organization.
Re: util_ldap [Bug 29217] - Remove references to calloc() and free()
At 12:33 PM 6/11/2004, William A. Rowe, Jr. wrote: The proper logic to add to a cache is wrlock test if exists again add element unlock because there is a race condition in the logic below rdlock test if the element exists >> race is here, prior to wrlocking, another thread may wrlock->insert promote to wrlock insert unlock Wow, how about that. I just (as in within the last hour) read an article in the July issue of DDJ[1] that talked about replacing Singleton (WRowe's second example) with with Double-Checked Locking (WRowe's first example) and the problems that still exist because of compiler optimization. What it boils down to is if this: wrlock test if exists again add element unlock can be broken down as this: wrlock test if exists again allocate element fill in element insert element unlock then the compiler may optimize this as: wrlock test if exists again allocate element insert element >> race is here, prior to filling in element, another thread may >> read element, and use element that hasn't been filled in yet. fill in element unlock Does the "add element" step guarantee that it won't insert the element into the cache until it is fully constructed, no matter what the optimizer does to the code? Of course, this is only Part I of the article, Part II isn't until the August issue. [1] Dr. Dobb's Journal, www.ddj.com (http://www.ddj.com/articles/2004/0407/)
Re: Better error logging for mod_access
At 10:18 PM 6/8/2004, Rici Lake wrote: The patch is now posted to bugzilla as [Bug 29450]. I believe that conforms to the patches.html document cited below. Although that document says -C3 is acceptable, I have submitted it in the preferential -u format (which I also prefer, actually). It says use -u, but if you absolutely *can't* do -u, then of the remaining options, -C3 is the best, or at least, that is what it is meant to say.
Re: cvs commit: httpd-2.0 libhttpd.dsp
At 01:33 PM 3/4/2004, William A. Rowe, Jr. wrote: At 12:04 PM 3/4/2004, Greg Marr wrote: >At 12:00 PM 3/4/2004, William A. Rowe, Jr. wrote: >>At 09:55 AM 3/4/2004, Greg Marr wrote: >> >>>/incremental:no is the default, and MSDev will at times remove flags that it finds redundant, even ones that it added itself. It's a bit schizophrenic like that. >> >>uh wrong. with /debug incremental yes is the default but you have >>to pound it into the msdev's head. please fix/revert. >> >>>>> -# ... /dll /incremental:no /debug /machine:I386 /base:@"os\win32\BaseAddr.ref",libhttpd.dll /opt:ref >>>>> +# ... /dll /debug /machine:I386 /base:@"os\win32\BaseAddr.ref",libhttpd.dll /opt:ref >>>>... > >Odd, I thought non-incremental was the default, but the help says otherwise. Incremental is the default, for regular and debug, at least in VC6. > >Why would you not want incremental for a debug build anyway? Greg we are creating the release build there - we create a pdb for unwinding core dumps. Oh, duh. Yeah. It is an optimized binary - incremental is not a healthy way to release a final image. Again, please revert. I would if I could... I was just commenting on why I thought it happened.
Re: cvs commit: httpd-2.0 libhttpd.dsp
At 12:00 PM 3/4/2004, William A. Rowe, Jr. wrote: At 09:55 AM 3/4/2004, Greg Marr wrote: >/incremental:no is the default, and MSDev will at times remove flags that it finds redundant, even ones that it added itself. It's a bit schizophrenic like that. uh wrong. with /debug incremental yes is the default but you have to pound it into the msdev's head. please fix/revert. >>> -# ... /dll /incremental:no /debug /machine:I386 /base:@"os\win32\BaseAddr.ref",libhttpd.dll /opt:ref >>> +# ... /dll /debug /machine:I386 /base:@"os\win32\BaseAddr.ref",libhttpd.dll /opt:ref >>... Odd, I thought non-incremental was the default, but the help says otherwise. Incremental is the default, for regular and debug, at least in VC6. Why would you not want incremental for a debug build anyway?
Re: cvs commit: httpd-2.0 libhttpd.dsp
At 09:09 AM 3/4/2004, Joe Orton wrote: On Mon, Mar 01, 2004 at 05:49:52PM -, [EMAIL PROTECTED] wrote: > ake 2004/03/01 09:49:52 > > Modified:.libhttpd.dsp > Log: > add eoc_bucket.c to project I'm not qualified to review Win32 changes but did you mean to remove /incremental:no from the linker flags here as well as adding eoc_bucket.c? Can you add this change to the list of changes to include in the EOC bucket backport if it is really OK to backport for 2.0? /incremental:no is the default, and MSDev will at times remove flags that it finds redundant, even ones that it added itself. It's a bit schizophrenic like that. > -# ... /dll /incremental:no /debug /machine:I386 /base:@"os\win32\BaseAddr.ref",libhttpd.dll /opt:ref > +# ... /dll /debug /machine:I386 /base:@"os\win32\BaseAddr.ref",libhttpd.dll /opt:ref ...
Re: FileSystem v.s. Other Resources [was configurable Location?]
At 10:22 AM 2/5/2004, [EMAIL PROTECTED] wrote: Thanks for the feedback, Will. William A. Rowe, Jr. wrote: At 03:39 PM 2/4/2004, [EMAIL PROTECTED] wrote: But then if I play devil's advocate, someone could see the new directive and turn it on when it's not appropriate and cause Bad Things to happen. Mainly I'm looking for comments on whether this should be configurable or not. Yes, I'm one who will agree with your devil's position :) I know the problem you are trying to solve, and changing the behavior of isn't quite the solution... I'm only changing ... is unaffected. Well, that's not entirely true. The is affected indirectly, because it no longer applies. The behavior currently is: it applies to everything it matches. This would change it to: it applies to everything it matches unless it also matches a , in which case it doesn't apply.
Re: [patch] - digest nonce including MM bump, doc and changes.
Couldn't the new member be placed at the end of the request rec so that it's only a minor bump? + *) SECURITY - verification as to wether the nonce returned in the s/wether/whether/ + "A random value or the servers IP may be a good choise.\n" }, s/choise/choice/ +/* We need to create a nonce which: + * a) changes all the time (see r->request_time) + *below and + * b) of which we can verify that it is our own + *fairly easily when it comes to veryfing s/veryfing/verifying/ + *the digest coming back in the response. + * c) and which as a whole should not + *be unlikely to be in use anywhere else. "should not likely be in use" or "should be unlikely to be in use" +If none if configured a sensible, but not particular s/if/is/ s/particular/particularly/ -- Greg Marr [EMAIL PROTECTED]
Re: Creating HTTPD Tarballs
On Sun, 16 Nov 2003 18:45:25 -0700 "Paul Querna" <[EMAIL PROTECTED]> wrote: On Sun, 16 Nov 2003 17:15:35 -0800, Roy T. Fielding wrote > -1. I'm still of the mind that _every_ release should be recreatable. > Anything we put out there is going to be at least perceived as > official, > and we should take that into account. Every release is tagged. A tarball is not a release. Nothing is a release until AFTER the associated tarball has three +1 votes, at which point it becomes a release and should be tagged as such. Why not name the releases/tarballs from a Date? This is already done automatically every 6 hours. Doing it on demand shouldn't be any different.
Re: consider reopening 1.3
On Sun, 16 Nov 2003 16:21:04 -0500 Glenn <[EMAIL PROTECTED]> wrote: On Sun, Nov 16, 2003 at 04:12:20PM -0500, Jim Jagielski wrote: I may be misunderstanding you... or do you mean just have Apache 1.3 "APR aware" and not for 1.3 to *use* it per se, but allow for modules to call APR... That would be useful, but anything deeper than that would scare people I think... APR is just as "new" as Apache 2.0. The latter. Only that it be available so that I can spend my time developing with Apache2 paradigms and have most of them translate to usefullness on Apache 1.3. Sort of a like a forward-compatibility to 2.0 in the same way that ap_compat.h is a backward-compatibility from 2.0 to 1.3. I believe that there has been some discussion on this list in the past about people using APR with 1.3 modules. There should be no requirement that httpd use APR for a module to use it.
Re: [PATCH] PR 18388 Set-Cookie header not honored on 304(Not modified) status
I found some time to look for existing discussions on this... (should have done that earlier)... It isn't valid to send Set-Cookie on a 304. It is not valid to set a cookie in a 304 response. Please see section 10.3.5 of RFC2616. That is the reason Apache explictly lists headers that will be sent and why Set-Cookie isn't one of them." I don't see how 10.3.5 says that Set-Cookie is invalid. It says that entity headers aren't allowed, but Set-Cookie isn't listed under the Entity Header section. (In fact, it isn't listed in the spec at all.) I see that other people had the same thoughts in the first link.
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
At 02:23 PM 12/17/2002, Paul J. Reder wrote:
Yup, the coredump happened in the first call with the %d. I just
patched this second call without looking at the exp parm, then
failed to notice the warning... *sigh* must be near Christmas
vacation when it takes three passes to get something like this
right... ;)
Any reason not to just use apr_pstrcat(p, "Broken expires header ",
exps) and save the overhead of the psprintf?
Cliff Woolley wrote:
On Tue, 17 Dec 2002, Joe Orton wrote:
On Tue, Dec 17, 2002 at 05:10:05PM -, Bill Stoddard wrote:
else if (exps != NULL && exp == APR_DATE_BAD) {
/* if a broken Expires header is present, don't
cache it */
-reason = apr_pstrcat(p, "Broken expires header
%s", exp);
+reason = apr_psprintf(p, "Broken expires header
%s", exp);
Still not right - 'exp' is an apr_time_t, you mean 'exps' I guess?
mod_cache.c: In function `cache_in_filter':
mod_cache.c:543: warning: format argument is not a pointer (arg 3)
Oooh, yowtch... good call. I wasn't even looking at that part.
--
Greg Marr
[EMAIL PROTECTED]
Re: cvs commit: httpd-2.0/modules/loggers mod_logio.c
At 03:50 PM 11/1/2002, Greg Stein wrote: On Fri, Nov 01, 2002 at 06:07:53PM -, [EMAIL PROTECTED] wrote: >... > +++ BaseAddr.ref1 Nov 2002 18:07:52 - 1.22 > @@ -60,3 +60,4 @@ >mod_authz_groupfile 0x6FB10x0001 >mod_authz_host 0x6FB00x0001 >mod_authz_user 0x6FAF0x0001 > +mod_logio0x6FAE0x0001 For efficiency purposes, those numbers should be as close together as possible. FYI, these are as close together as possible. You can't specify the addresses with any finer granularity than 0x1. I don't recall how to find the size of the module; If you're on WinNT, you can use Quick View. I'm not sure in Win2K, other than just checking the size of the executable in Windows Explorer. Also, the reason for the 0x0001 at the end of the line is so the linker knows how much space you've allocated for the module. If it module is larger than that size, a warning will be issued at link time. -- Greg Marr [EMAIL PROTECTED]
Re: stable 2.0 trees
On Wed, 16 Oct 2002 19:24:22 -0400 Joshua Slive <[EMAIL PROTECTED]> wrote: >I'm +1 for creating 2.1 and 2.2 trees as proposed by Bill. My one thought about this proposal is that it is unclear whether or not this is attempting to emulate the Perl versioning scheme. If so, then it's backwards, since Perl uses even numbers for releases and odd numbers for development, but Bill proposed that 2.1 be the "stable" branch, and "2.2" become the "development" branch.
Re: Thread-unsafe libraries in httpd-2.0
At 10:41 AM 8/16/2002, Rodent of Unusual Size wrote: > > And, my point back to you is that should be part of the > documentation > > of the module NOT of httpd-2.0. > >IMNSHO, that is *such* BS. If someone has a working Web server and >upgrades following our recommendations, and things stop working, >it's not PHP that will get blamed. PHP still works just fine; there >always has been the potential for trouble with threaded libraries, >but that wasn't an issue because the Web server didn't use threads. > >What changed? The Web server; it started supporting threads. So it >behooves the Web server to document the potential for problems. Why >should the burden be put on PHP, or any other module for that >matter? *They* weren't the ones that enabled threading. I don't see what the big deal is here. It doesn't have to be one or the other. It REALLY is up to PHP and mod_perl to let their users know that they aren't thread-safe. It would also be helpful for Apache to let its users know that there are potential problems due to non-thread-safe third-party modules. As someone else posted, put a notice in the Apache distribution area that Apache 2.0 now supports threaded models, and before upgrading to Apache 2.0 and using one of the threaded models, users should check with each third-party module that they use to see if they're thread-safe. Then PHP and mod_perl can put notices in their distribution areas that some of the libraries they use aren't thread-safe, and that until this is fixed, users should not use any of the threaded models in Apache 2.0, and recommend use of the non-threaded models. -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Contributing patches page
http://httpd.apache.org/dev/patches.html Under "Submitting your patch", the first sentence still refers to the old mailing list: "If you are a subscriber to new-httpd",
Re: [1.3] Proxy fixes and FWD: Re: [apache-modules] Setting bytes_sent in Request Record while generating all headers by myself in Apache 1.3]
At 01:30 PM 05/29/2002, Thomas Eibner wrote:
>Index: proxy_http.c
>===
>RCS file: /home/cvspublic/apache-1.3/src/modules/proxy/proxy_http.c,v
>retrieving revision 1.98
>diff -u -r1.98 proxy_http.c
>--- proxy_http.c21 Apr 2002 21:16:39 - 1.98
>+++ proxy_http.c29 May 2002 17:04:38 -
>@@ -350,6 +350,20 @@
> * where the original request came from.
> */
> ap_table_mergen(req_hdrs, "X-Forwarded-For",
> r->connection->remote_ip);
>+if (r->proxyreq == PROXY_PASS) {
>+const char *buf;
>+/* Add X-Forwarded-Host: so that upstream knows what the
>+ * original request hostname was.
>+ */
>+if ((buf - ap_table_get(r->headers_in, "Host"))) {
I think this should be "buf =" instead of "buf -".
--
Greg Marr
[EMAIL PROTECTED]
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"
Re: cvs commit: httpd-dist README.html
On Thu, May 23, 2002 at 06:45:03PM -, [EMAIL PROTECTED] wrote: > slive 02/05/23 11:45:02 ... > +Do not download from www.apache.org. Please use a mirror site > + to help use save apache.org bandwidth. should that be "help us save"? -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Re: FW: Apache 2.0.36 and xcopy on WinNT
At 03:00 PM 05/10/2002, William A. Rowe, Jr. wrote: >At 01:18 PM 5/10/2002, you wrote: >>At 01:55 PM 05/10/2002, William A. Rowe, Jr. wrote: >>>Ahhh. Win95 and forward do support the /y flag. Since WinNT does >>>not, I'll revert the change that presumed our modern >>>command.com/cmd.exe based xcopy'ies all work. >>> >>>Expect a fix in .37 - thanks for the report! >> >>You can put the /y switch in the COPYCMD environment >>variable. WinNT's xcopy ignores this, but Win2K's will pick it up. > >Won't solve the problem. You have no idea how many 'Y's they must >push, nor how that will break in-IDE builds :-) Will revert to the >old <.y. What do you mean by "how many 'Y's they must push"? I also don't see how it can break in-IDE builds. We use it with in-IDE builds all the time. If you're worried about it affecting other xcopy commands, set the COPYCMD variable to /y, call xcopy, and then clear it again. -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Re: FW: Apache 2.0.36 and xcopy on WinNT
At 01:55 PM 05/10/2002, William A. Rowe, Jr. wrote: >Ahhh. Win95 and forward do support the /y flag. Since WinNT does >not, I'll revert the change that presumed our modern >command.com/cmd.exe based xcopy'ies all work. > >Expect a fix in .37 - thanks for the report! You can put the /y switch in the COPYCMD environment variable. WinNT's xcopy ignores this, but Win2K's will pick it up. -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
RE: PR 7966
At 10:10 PM 04/11/2002, Ryan Bloom wrote: > > From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > > On Thu, Apr 11, 2002 at 07:02:48PM -0700, Ryan Bloom wrote: > > > Dollars to Donuts, the problem is that the C-L filter isn't > removing the > > > C-L header from the request. I won't have time to look at this > for a > > > few weeks though. > > > > The request? Don't you mean the file? > > > > Taking a quick look at default_handler: > > > > server/core.c line 3208: > > ap_set_content_length(r, r->finfo.size); > > > > Isn't that call bogus? Why just not let the C-L filter handle it? > >No, it isn't bogus. If the file isn't changed, then the call is >correct. It is only bogus if the content is changed, as it is with >SSI requests. If the C-L filter can't verify the C-L, it should be >removing it from the request. If it doesn't, that is the bug. Isn't the filter that changes the content responsible for removing the C-L? Otherwise, the C-L filter would either remove the C-L every time, or have to buffer the entire thing. -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
RE: cvs commit: httpd-2.0 STATUS
At 09:50 AM 04/08/2002, Ryan Bloom wrote: > > Ok, I've got two versions of httpd-2.0.35-i686-pc-linux.tar.gz, one > > from a 2.2.18 RedHat 7.0 machine, and the other from a 2.4.9 > RedHat 7.2 > > machine. What do I do with these now? How do I sign them? (I need > to > > put my public key in the KEYS file, but I'm a little clumsy with > gpg.) > >If you key isn't already in the KEYS file, you can't release those >binaries. Uh, why not? As long as the key is in the KEYS file before the binaries are posted, what difference does it make when it was added? -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Re: 1.3.24-dev new warning...
At 01:07 PM 04/19/2002, William A. Rowe, Jr. wrote: >At 10:03 AM 3/19/2002, you wrote: >>At 10:42 PM -0600 3/7/02, William A. Rowe, Jr. wrote: >> >C:\clean\apache-1.3\src\modules\proxy\proxy_util.c(565) >> > : warning C4018: '<' : signed/unsigned mismatch >> > >> >n = ap_bread(f, buf, MIN(buf_size, len - >> total_bytes_rcvd)); >> >>I had posted a patch regarding this a bit ago... Any feedback? I was >>not able to recreate the exact error messages locally on any of >>my machines, so I couldn't see if it solved the specific problem >>(without creating more :) ). > >Doh! MIN() is implemented in terms of a terniary, and those are very >broken in terms of the result type on win32. Casting the MIN() back >to >the arg type of ap_bread() should be sufficient. I doubt it. The warning is about the '<', which occurs because buf_size is size_t, and len is off_t. BTW, I've never had any troubles with the result type of ?: on Win32. It's always the result type of the true result, which is what it should be, as far as I've seen. Could you be a bit more specific? -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
RE: Using Apache 1.3 modules with 2.0 was Re: Please help kill httpd-2.0 bugs...
At 12:03 PM 02/27/2002, Ryan Bloom wrote: > > On Wed, Feb 27, 2002 at 04:44:03PM +, Thom May wrote: > > However, that brings up a point: > > > > Can we detect when a 1.3 module will be used with 2.0? One of my > > housemates was trying to install the PHP 1.3 module with 2.0.32 on > > Win32 last night. It just said as this bug does too: > > > > Cannot load E:/apache/Apache2/modules/ApacheModuleJServ.dll into > server: > > The specified module could not be found. > > > > Can we detect and report an suitable error message in this > > case? -- justin > >Yeah, that's actually trivial. The module structure has a key that >is the Apache version number. Look at MODULE_MAGIC_COOKIE. Just do >a quick comparison when we load the module, and output a valid error. Not on Windows. You will not be able to even load the module. The LoadLibrary call will fail, since the module is linked against functions that don't exist. That is a standard system error message from using LoadLibrary to load a DLL when a required dependency doesn't exist. -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Re: [patch] per-child (Re: 2.0.32 has been released.)
At 09:37 AM 02/14/2002, Jeroen Massar wrote: >First I noticed that the KEYS file is missing from the tar file. The KEYS should not be in the tar file. You have to get the KEYS from a trusted source, and the file you are attempting to verify is not a trusted source, otherwise you wouldn't be trying to verify it. -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Re: Releases, showstoppers, and vetos
At 03:53 PM 02/06/2002, Rodent of Unusual Size wrote: >Greg Marr wrote: > > > > I read that last sentence as: "An issue becomes a showstopper when > > it is listed as such in STATUS, and remains one until someone > vetoes > > it, at which time it is no longer a showstopper. ..." > >I think that's bogus, too. If someone thinks something is serious >enough to stop a release, they should be no more overridable than >any other block (read: veto). I find the idea of being able to veto >a showstopper completely ludicrous. :-) It could be. I wasn't expressing an opinion one way or another, just attempting to interpret the current guidelines. -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Re: Releases, showstoppers, and vetos
At 03:33 PM 02/06/2002, Rodent of Unusual Size wrote: >"Roy T. Fielding" wrote: > > > > A showstopper, aside from a yet-to-be-reverted veto, can be > > moved from one section of STATUS to another by the RM (or > > anyone, for that matter) whenever they want. It is only > > a showstopper if we ALL agree it is. The category only exists > > to simply remind us of what needs to be fixed. > >Not codified, and certainly not clear: > > > Showstoppers > > Showstoppers are issues that require a fix be in place > > before the next public release. They are listed in the STATUS > > file in order to focus special attention on the problem. An > > issue becomes a showstopper when it is listed as such in > > STATUS and remains so by lazy consensus. > >'Consensus' means vetos apply, as opposed to 'majority.' FYI, from my reading, I concur that vetos apply in this situation, but they apply to the issue being a showstopper, not to the showstopper stopping a release. I read that last sentence as: "An issue becomes a showstopper when it is listed as such in STATUS, and remains one until someone vetoes it, at which time it is no longer a showstopper. Thus, a consensus is required for an issue to be a showstopper, and anyone can move something out of the showstopper category at any time." -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Re: [PATCH] improve mod_cgid robustness
At 06:44 AM 01/28/2002, Jeff Trawick wrote: >On systems that can accept new CGI requests faster than the daemon can >fork, it is easy to fill the listen queue on the Unix socket and get >ECONNREFUSED, resulting in a 500 error going back to the browser. It >is alarming to see a zillion requests for the same resource in the >access log, with large numbers of them getting 500 instead of 200. Shouldn't these be 503 Service Unavailable instead of just a plain 500? -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Re: Tag 1.3.23?
At 04:13 PM 01/21/2002, William Rowe wrote: >The following (decorated, default) exported symbol names, and the >attached >asm output from footest and footest2 illustrate that _stdcall is >ignored >for vararg prototypes :) looking up __stdcall in the MSVC help gives this: The __stdcall calling convention is used to call Win32 API functions. The callee cleans the stack, so the compiler makes vararg functions __cdecl. -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Re: Tag 1.3.23?
At 12:53 PM 01/18/2002, Bill Stoddard wrote: >If we break binary compatability with even one function, we need to >bump the MMN major. That wouldn't do anything, because a module using one of these functions will never get a chance to check the MMN. The Windows loader will prevent it from loading in the first place, since it is linked against a function that doesn't exist. The breaking of binary compatibility in this case is at the link layer. -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Re: Proposal: Future release strategies
At 02:47 PM 09/06/2001, Bill Stoddard wrote: > > Well - the vote on the table is to take the LDAP code out of > Apache v2.0 > > - but the next question is when it's removed, what do we do with > it? > >I will probably be a user of mod_ldap, but right now, I am inclined >to remove it from the >core and put it in its own repository for the same reasons I want to >keep mod_gz out. Why not just put them in modules/experimental? Isn't that what it's for? -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Re: apxs broken
At 01:32 PM 09/06/2001, Stas Bekman wrote:
>Also the regex that does s/(foo)/{foo}/ is cleaner in case someone was
>doing $(foo)_bar with the current patch, this will break, since it
>makes
>$foo_bar, whereas it should be better ${foo}_bar.
A regexp is overkill in this case, assuming that the input is a known
set, and all parens need to be changed to braces.
--- apxs.in.orig Fri Sep 7 01:27:52 2001
+++ apxs.in Fri Sep 7 01:27:56 2001
@@ -245,6 +245,8 @@
open IN, $file or die "cannot open $file: $!";
while (){
+# $(foo) => ${foo}
+tr/()/{}/;
if (/^\s*(.*?)\s*=\s*(.*)$/){
$rh_config->{$1} = $2;
}
@@ -261,7 +263,6 @@
my $val = exists $config_vars{$arg}
? $config_vars{$arg}
: $config_vars{lc $arg};
-$val =~ s/[()]//g;
$result .= eval qq("$val");
$result .= ";;";
$ok = 1;
@@ -270,7 +271,7 @@
if (exists $internal_vars{$arg} or exists
$internal_vars{lc $arg}) {
my $val = exists $internal_vars{$arg} ? $arg : lc
$arg;
$val = eval "\$CFG_$val";
-$result .= eval qq("$val");
+$result .= eval qq("$val") if defined $val;
$result .= ";;";
$ok = 1;
}
--
Greg Marr
[EMAIL PROTECTED]
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"
Re: [PATCH] optimization for setting of allowed methods
At 12:58 PM 09/06/2001, Ryan Bloom wrote: >> Weren't these "method numbers" recently removed so that there are >> no "standard" methods, and all the methods are added the same way >> at run time? > >In order to keep backwards compat, keep the patch small, and keep >the performance high for the standard HTTP methods, the old macros >were kept. ... they are gauranteed to have the same value as the >constant though. Ah, I missed that part of it. Thanks. -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Re: [PATCH] optimization for setting of allowed methods
At 11:50 AM 09/06/2001, Brian Pane wrote: >This patch eliminates some run-time conversion of method names to >numbers (something that I noticed while looking through function >call profiles). > >RCS file: /home/cvspublic/httpd-2.0/server/core.c,v >-ap_allow_methods(r, MERGE_ALLOW, "GET", "OPTIONS", "POST", NULL); >+ap_allow_standard_methods(r, MERGE_ALLOW, M_GET, M_OPTIONS, >M_POST, -1); > >RCS file: >/home/cvspublic/httpd-2.0/modules/mappers/mod_negotiation.c,v >-ap_allow_methods(r, REPLACE_ALLOW, "GET", "OPTIONS", "POST", >NULL); >+ap_allow_standard_methods(r, REPLACE_ALLOW, M_GET, M_OPTIONS, >M_POST, -1); Weren't these "method numbers" recently removed so that there are no "standard" methods, and all the methods are added the same way at run time? -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Re: Fw: Regarding lower-case HTML tags
At 11:12 PM 09/04/2001, William A. Rowe, Jr. wrote: > > > I've been using tidy, from the w3c, for a while now, to do > > > pretty-reformatting of HTML documents. One of the things that > it does is > > > lower-case HTML tags. I was wondering, in light of comments > made a week > > > or two ago, whether it would be worthwhile to do this with > files in the > > > docs as I a working with them? The reason it does that is that XML is case-sensitive for tag names, and the HTML working group chose to use lowercase for XHTML. Thus, if the pages were ever to be marked as XHTML, they'd need to be lowercase. -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
At 06:19 PM 09/03/2001, Graham Leggett wrote: >Greg Marr wrote: > > > How exactly do you use Cache-Control directives so that the > content that > > is cached is before includes are processed, and that when it is > > retrieved from the cache, the includes are processed? It just > doesn't > > work that way. In this case you have to put the includes before > the > > cache. > >mod_cache and mod_include should have no knowledge of each other. Exactly. They shouldn't care in which order they are run, that should be up to the admin. You're saying the opposite, that mod_cache should only be able to run after mod_include. >mod_cache is interested in content going to the browser. You're interested in having mod_cache only interested in content going to the browser. There's a difference. >There are already two caches in the loop (a transparent ISP cache, >and the browser cache) so if mod_include doesn't generate proper >Cache-Control: headers >then mod_includes is broken already without any help from mod_cache. This has absolutely nothing to do with using mod_cache to cache the page just before it is processed by mod_include, and processing the page retrieved from the cache using mod_include. >I don't see any reason why mod_cache should interfere with >mod_include (or vice versa). Apparently you do. >mod_cache only cares about what is spat out at the end of the filter >chain Why should it be restricted like that? That makes it less useful. >One of the fundamental design points about mod_cache was to separate >it from all other modules (specifically mod_proxy). Tying mod_cache >behaviour to mod_include (or any other module) is a step backwards >in the design. So why are you saying it should be done that way? It should be able to be placed at any point in the filter chain. Requiring it to come after mod_ is tying its behavior to mod_, saying that mod_ must process the file before it is cached. -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
Graham Leggett <[EMAIL PROTECTED]> wrote: > Greg Marr wrote: > > > In Ian's particular case, that is incorrect. The value of his > > includes vary from request to request, so he needs the cache to > > be before the includes filter. > > This isn't necessary - simply use the Cache-Control directives > correctly so that the includes content is not cached. How exactly do you use Cache-Control directives so that the content that is cached is before includes are processed, and that when it is retrieved from the cache, the includes are processed? It just doesn't work that way. In this case you have to put the includes before the cache. > mod_cache should behave exactly like a transparent cache would. In your application, yes, not in the one in question. > No, I'm saying use the Cache-Control directives correctly exactly as > a transparent proxy would. That's not the desired behavior.
Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
On Sat, 01 Sep 2001 14:47:55 +0200 Graham Leggett <[EMAIL PROTECTED]> wrote: > Bill Stoddard wrote: > > > Yep, you definitely need CACHE_OUT to be a CONTENT filter in this > > case since INCLUDES is a CONTENT filter and you need INCLUDES to > > be run after CACHE_OUT. > > I disagree - includes is something that should be cached as it is a > performance bottleneck. In Ian's particular case, that is incorrect. The value of his includes vary from request to request, so he needs the cache to be before the includes filter. > If the user specifies "cache this URL range" it would be wrong to > override the user's wishes and not cache something. You're saying that we should override the user's wishes and cache the page with the request-specific information instead of before these are added.
