On Sun, Feb 26, 2006 at 11:55:31PM -0800, Sander Temme wrote:
> Issues.apache.org, which is running trunk or something very close to
> it to debug the JIRA issues, has some child processes sucking extreme
> quantities of CPU. For instance:
Also, we're getting reports that IE clients on Windows
On Sun, Feb 26, 2006 at 11:55:31PM -0800, Sander Temme wrote:
> (gdb) bt
> #0 allocator_free (allocator=0x60167ad0,
> node=0x60186e80)
> at ../../../apr/memory/unix/apr_pools.c:343
> #1 0x203b6540 in apr_pool_destroy (pool=0x60186ea8)
> at ../../../apr/me
On Mon, Feb 27, 2006 at 12:55:47AM -0800, Justin Erenkrantz wrote:
> But, in the eor_bucket_destroy, it tries to clear the request pool. By the
> time we get here though, apr's already killed off our sub pools - including
> the request pool. Oops.
Parting shot that would &#x
On 2/27/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
> Also, we're getting reports that IE clients on Windows consistently get> 408s (server timeout) immediately from httpd. Some users with Safari and> Firefox can see this problem occassionally, but MSIE triggers it a good
> portion of the time.I
On 2/27/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
Meanwhile I doubt that Tomcat sent the correct response. But maybe it is just me,so lets see what I found from the dump Justin sent over to me:
I'm still digesting this, but some quick questions and answers:
Were the other packets in this strea
On 3/7/06, Jim Jagielski <[EMAIL PROTECTED]> wrote:
> I would suggest that the "bandaid" code no longer be
> compile time but rather runtime, using a
> "force-flush=true" param to the AJP worker.
I'd prefer that we not defer this decision to the users - we should
either enable it or don't. But, m
On 3/7/06, Jim Jagielski <[EMAIL PROTECTED]> wrote:
> Feh. No way. The argument would hold true if mod_jk
> did not provide just the sort of control that you say
> we shouldn't provide to users/admins, and control that
> *varies* from setup to setup.
Why must we offer a shiny knob that the average
On 3/8/06, Jim Jagielski <[EMAIL PROTECTED]> wrote:
> Any other comments about the patch? Should I just
> commit the revised one and we can tweak from
> there...
As I said in my other email, turning flushing off means that we expose
ourselves to a DoS. Ouch. -- justin
On 3/9/06, Brad Nicholes <[EMAIL PROTECTED]> wrote:
> What do you mean? The actual directives are only supported in trunk
> through the compatibility module mod_access_compat. This module as well
BTW, can we consider dropping the warning about the deprecated authz
directives in mod_access_compat
On 3/11/06, Paul Querna <[EMAIL PROTECTED]> wrote:
> But, the 'lets do this quickly and make it work' part of me says, we can
> design something very simple and 'stupid', that uses the knowledge of
> how mod_cache works.
mod_disk_cache should work over NFS. =) -- justin
On 3/1/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> I've enjoyed responding to Justin's detailed questions, and appreciate the
> very
> few comments which have arrived. That said; I'm closing this survey on March
> 8th, please get any final offers of help above, additional questions or
On 3/18/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> Sorry Justin, tried to ping you last week even in anticipation of this
> question, but you weren't to be found or were ignoring me ;-) I trust this
> syncs with your expectations.
I wasn't ignoring you. However, anything other than em
On 3/21/06, Joe Orton <[EMAIL PROTECTED]> wrote:
> What supported versions of GNU libtool do this, what platform?
1.3 and 1.4 variants that are long unsupported or were tweaked
incorrectly by the packager. The stock 1.5 series gets it right.
> Can you
> give a repro case so I can report this ups
On 4/17/06, Tyler MacDonald <[EMAIL PROTECTED]> wrote:
> But bringing apr-config in myself seems to defeat the purpose of using apxs
> in the first place. Is this a known issue or something I'm doing wrong? Is
> there a better way?
apxs is designed to compile your custom module yourself - not to a
On 4/18/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> > I know :-).
> > But I would like to see this inside the apr framework as it
> > seems to me that serf has some acceptance problems here in the httpd
> > community. Please correct me if this impression is wrong.
>
> Your impression is w
On 4/18/06, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote:
> Also, what are people's thoughts on including sha1 signatures in our
> official dist? We havn't heretofore, is there any benefit? The PGP
As long as you tweak roll.sh, I don't care. =) -- justin
On 4/18/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
> it sounds like we have got some pretty good ideas so far.
> the next step is to put them on the Wiki Page (or create a 2nd wiki
> page just for httpd and APR projects to reduce the clutter
>
> the URL is here:
> http://wiki.apache.org/general/Sum
On 4/18/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
> Be careful when it comes to scoping work.
> I found last year that some students last year will do what is asked
> for, not more.
Asking for too much will also scare away folks. *shrug* At the end
of the SoC program, if we received a set of te
On 4/19/06, Jim Jagielski <[EMAIL PROTECTED]> wrote:
> Before I t/r 1.3, I'll be updating the files to reflect the
> new copyright. We can determine some better way of doing it
> post-release :)
No. Please do not update any copyright years.
We are only supposed to indicate the year of *first* pu
On 4/19/06, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 19, 2006 at 03:19:39AM -0500, William A. Rowe, Jr. wrote:
> > Whoa - that's not correct(!) Although the details are tricky, and although
> > copyright no longer requires 'registration' of the copyrighted material, you
> > still
On 4/19/06, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote:
> Eek, This has already been done, for trunk and for the 3 branches.
Ugh.
Then, we should just update to Jackrabbit's license clause if we're
going to have churn in that area. But, if we're going to touch it,
then we should change it to th
On 4/19/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
> http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit/HEADER.txt
The only pedantic item I see with that wording is that it says "the
Apache Software Foundation" instead of "The". ;-) *ducks and run*
-- justin
On 4/19/06, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote:
>
> Candidate tarballs for 2.0.57 are now available for testing/voting at;
>
> http://httpd.apache.org/dev/dist/
>
> This doesn't include a changed notice-of-license text though, which is a
> potential open issue.
I'm -1 due to the c
On 4/21/06, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote:
> We know that now, but those commits went through before it became so
> clear that our previous practise was so wrong.
The entire email exchange happened while the US West Coasters were
asleep. I sent an email saying, "Don't do that" as so
On 4/21/06, Jim Jagielski <[EMAIL PROTECTED]> wrote:
> You know, this is hardly the first time we've done that... Yes, it's
> been awhile since we made those unilateral changes, but by the
> above standards, what we had even before wasn't "really" correct,
> since those had changed copyrights on fi
On 4/21/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> How is this a showstopper? As has been pointed out, your comments are late
> to the table, and this certainly isn't a change in existing practice, and
> most certainly doesn't invalidate the (initial and appropriate) copyrights.
Bah.
On 4/21/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> I really have no problem if Cliff posts to the list telling us "It is
> not necessary to update copyright dates" - and if he does that, we will
> revert before rolling 2.2.0.
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/20
On 4/21/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
> You are correct. Only the years in which the file was actually changed
> should be listed in the copyright.
If we want to get pedantic, it should only be year of first publication. ;-)
For reference, here's Larry Rosen's post to legal-discus
On 4/21/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> You are right that we don't update *all* the copyrights, nobody debated that.
> We had a simple (too simple) search of touched files to refresh copyright, and
> I have no issue if we should undo that and selectively update copyrights on
On 4/24/06, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote:
> Tbh, I'm -0.5 on this. It's complex enough as it is trying to get
> releases out, and 1.3 hasn't even tagged yet.
My concern is that issuing three announcements in the span of one week
is *very* confusing to our users. Either 2.0 and 1.3
On 4/24/06, Sander Temme <[EMAIL PROTECTED]> wrote:
> How about, we lead with 2.2.2, and note in the announcement that 2.0
> and 1.3 releases should be available later this week. This goes out
> to the Slashdots etc. of this world. When 2.0 and 1.3 are ready, we
> can update the website but not sen
On 4/27/06, Joshua Slive <[EMAIL PROTECTED]> wrote:
I know there are people who still hold the idealistic view that we
shouldn't be obscuring email addresses at all. Although I agree in
principle, I think the world has passed that view by.
I think that obfuscation is completely pointless. You
On 4/27/06, Tyler MacDonald <[EMAIL PROTECTED]> wrote:
LibXML2 is released under the MIT license. From what I understand, some
parts of Apache2 are subject to the same license, so a project released
that's linking against LibXML2 would still fall under the terms of the
Apache License 2.x.
Does t
On 4/28/06, Tyler MacDonald <[EMAIL PROTECTED]> wrote:
I guess it's a bit off-topic for [EMAIL PROTECTED] I would have sent it
to
legal-discuss in the first place, but that list is not open to the public.
:-(
You can send emails to it even if you aren't subscribed... -- justin
On 4/28/06, Joshua Slive <[EMAIL PROTECTED]> wrote:
As I said, I'd love to agree with you. But why don't you try asking
100 random subscribers to our users lists or 100 random bug submitters
whether they think it is obvious that their email address will be made
public. A couple years ago, they
On 5/3/06, Paul Querna <[EMAIL PROTECTED]> wrote:
I am okay with forcing people to wait for 2.4. Develop in trunk and/or
devel-branches freely. Don't worry about back porting it to the stable
branch, IMO.
+1. -- justin
On 5/3/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
However, I see no reason to start by changing the existing
module names and assuming that one cache fits all.
For simplicity sake, I agree. Let's call this new thing
mod_cache_generic or mod_frobit. However, let's not touch mod_cache
and f
On 5/10/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
On May 10, 2006, at 2:10 PM, William A. Rowe, Jr. wrote:
> Just a footnote from legal-discuss that the win32 nmake -f
> Makefile.win install
> isn't moving NOTICE (yet) to the target tree, and once we do that,
> we need to
> then staple it i
On 6/8/06, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote:
There are quite a few reasonable alternative strategies for dealing with
that kind of scenario. Does the ASF have such a policy as a matter of
course, regardless of the severity of such an action?
As that hasn't happened yet, there is no s
On 6/8/06, Joe Orton <[EMAIL PROTECTED]> wrote:
Thanks for doing the research, Roy.
Ditto.
On Wed, Jun 07, 2006 at 02:03:33PM -0700, Roy T. Fielding wrote:
> Okay, let me put it in a different way. The alternatives are
>
> 1) retain the status quo, forbid distributing ssl binaries, and
> in
On 6/8/06, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote:
Another option is that we could ask the ASF to formally consider upping
roots and changing jurisdiction. I have little doubt over what the
answer would be, but I'd prefer that we exhaust all of the alternative
options before doing anything w
On 6/14/06, Shanti Subramanyam <[EMAIL PROTECTED]> wrote:
Would it be possible to include documentation somewhere
(README.platforms ?) that suggests to users to use the Studio compiler
which can be downloaded for free from
http://www.opensolaris.org/os/community/tools/sun_studio_tools/
Sure - f
On 6/16/06, Shanti Subramanyam <[EMAIL PROTECTED]> wrote:
Here is the patch :
--- README.platformsFri Jun 16 09:12:33 2006
+++ README.platforms.orig Thu Jun 15 13:13:50 2006
@@ -95,12 +95,4 @@
http://www.apache.org/dist/httpd/patches/apply_to_2.0.49/aix_xlc_optimization.patch
(
On 6/16/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
huh?
why is the licensing terms stopping us recommending something?
we recommend VC2005 for windows and that it commercial, I don't see
the difference.
(and yes.. I saw mads's comment that this studio is free if your
register)
Recommending pro
On 6/16/06, Mads Toftum <[EMAIL PROTECTED]> wrote:
Hmm, I think that page needs updating. AFAIK sun studio has been free
since version 11. In particular:
http://developers.sun.com/prodtech/cc/downloads/index.jsp
yeah, it does mention "FREE for SDN members" - but that's just another
way of asking
Removed this address from the mailing list...nothing else to see... -- justinOn 29 Jun 2006 12:06:33 -0500, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:Sorry but this e-mail account has been disabled
Please redirect all your correspondence to: e-info(at-commerce)llion(dot)net
On 7/11/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
On Jul 11, 2006, at 2:24 PM, Paul Querna wrote:
> It would of been helpful to discuss this change before doing it on
> [EMAIL PROTECTED] Last time someone just went off and did it, we ended up
> reverting it all again.
That was for updating
On 7/17/06, Paul Querna <[EMAIL PROTECTED]> wrote:
I have reverted the ifneq in r422925. Any suggestions on how to best go
around making this configured from configure?
EXTRA_PROGRAMS=
case $host in
*mingw*)
;;
*)
EXTRA_PROGRAMS="fcgisupport blah blah blah"
;;
esac
AC_SUBST(EXTRA_PROGR
On 7/19/06, Luis Fco. Ramirez Daza Glez <[EMAIL PROTECTED]> wrote:
How people that just use the mod_aspnet module can contribute or vote, to
make the mod_aspnet project continue?
mod_aspdotnet can and is encouraged to find a home outside of the ASF.
There are plenty of other places out there th
On 7/20/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
I guess I can't change the log entry anymore. All I can do is adjust the CHANGES
entry. Would that address your concerns?
svn propchange --revprop -r423886 svn:log https://svn.apache.org/repos/asf/
HTH. -- justin
On 8/17/06, Graham Dumpleton <[EMAIL PROTECTED]> wrote:
Also, dist/setup.py in mod_python source contains:
...
But I think this was a workaround for older version of Mac OS X.
What is the actual error you are getting when building?
Um, how are you building?
Per README, I'm running:
$ ./confi
On Thu, Aug 17, 2006 at 06:58:52PM -0400, Graham Dumpleton wrote:
> So, agree that it is not good that the malformed argument is getting in
> there, but still don't know why it is dying for you unless it is specifically
> related to you using Apache from subversion trunk and thus why no one else is
On 8/30/06, Rainer Jung <[EMAIL PROTECTED]> wrote:
The most recent kernel update patch is 118833-20 (SPARC versions, X86
should be analogous).
Yah, that bug has been fixed. (Paul reported the bug early on, I think.)
We have also heard reports that the SSL crypto engine on the T2000's
is horke
On 10/2/06, Garrett Rooney <[EMAIL PROTECTED]> wrote:
Or the even more readable:rv = do_something(args);if (rv == APR_SUCCESS) {}+1.Using the comma operator is orders of magnitude too nasty/subtle to use. -- justin
On Fri, Oct 27, 2006 at 01:28:57PM -, [EMAIL PROTECTED] wrote:
> Author: minfrin
> Date: Fri Oct 27 06:28:56 2006
> New Revision: 468373
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=468373
> Log:
> mod_cache: Pass the output filter stack through the store_body()
> hook, giving each cache
On 10/29/06, Graham Leggett <[EMAIL PROTECTED]> wrote:
The current expectation that it be possible to separate completely the
storing of the cached response and the delivery of the content is broken.
We have a real world case where the cache is expected to process a many
MB or many GB file compl
On 10/29/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
I strongly disagree because MOST of the flaws in the HTTP/1.1 implementation,
mod_proxy and even mod_cache exist because the development happened with
insufficient oversight.
Only code that's actively reviewed on trunk/ is going to get
On 10/30/06, Issac Goldstand <[EMAIL PROTECTED]> wrote:
Can you clarify the above a bit? I don't understand what you're
referring to. Looking at the 2.2.3 tag, what versioning is currently in
place?
Look at disk_cache_register_hook.
/* cache initializer */
ap_register_provider(p, CAC
On 10/30/06, Issac Goldstand <[EMAIL PROTECTED]> wrote:
Looking at provider.c, a couple of questions spring to mind:
1) Why isn't this part of apr-util? (it seems similar to apr_optional.h
- just intended for vtables rather than functions, and with this version
info)
apr_optional is an ugly hac
On 10/30/06, Joe Orton <[EMAIL PROTECTED]> wrote:
A simple general-purpose disk cache which makes no assumptions about
speed of backend, speed of storage or speed of clients; is
single-threaded and does not involve any multi-process synchronisation
beyond open/O_EXCL. Specifically:
+1. I woul
On 10/30/06, Joe Orton <[EMAIL PROTECTED]> wrote:
So here's another assumption to consider with this work...
I keep seeing people talk about the mod_cache interface as an
externally-visible API for which we must maintain API/ABI compatibility.
But mod_cache.h is not installed, so this API is not
On 10/30/06, Joe Orton <[EMAIL PROTECTED]> wrote:
On Mon, Oct 30, 2006 at 10:26:18AM -0700, Justin Erenkrantz wrote:
> My concern with this is we should be careful not to teach the
> providers about the fact that it is sitting in an output filter chain.
This is solvable if desired,
On 10/30/06, Joe Orton <[EMAIL PROTECTED]> wrote:
1) change the store_body interface to allow the storage provider direct
access to f->next, so it can flush buckets up the output filter chain
when they have been stored. As seen on trunk.
2) keep the interface as-is, but read buckets in mod_cach
On 10/30/06, Nick Kew <[EMAIL PROTECTED]> wrote:
-1 to doing that with local, static files. And once you start
making exceptions to a rule, that becomes BAD complexity.
What exceptions are you talking about?
Everything would be treated as a char *, size_t pair. It's quite
simple, actually...
On 10/31/06, Plüm, Rüdiger, VF EITO <[EMAIL PROTECTED]> wrote:
That seems to be an important point to me. Although I never used
the fd caching of mod_mem_cache this would mean we actually would
have to dump this feature. This looks bad to me. Isn't this a showstopper
for implementing #3 as new in
On 10/31/06, Graham Leggett <[EMAIL PROTECTED]> wrote:
On Tue, October 31, 2006 2:31 pm, Joe Orton wrote:
> To determine writability of the output filter chain is not as simple as
> exposing writability of the socket. An output filter may block on
> writes because it is blocked on a read from t
On 10/31/06, Graham Leggett <[EMAIL PROTECTED]> wrote:
Hypothetically, if somebody else cared to redesign the output filters just
for the cache, and some effort was spent by that somebody else to make
sure any disruptive changes were either minimised or prevented where
possible, would development
On 10/31/06, Graham Leggett <[EMAIL PROTECTED]> wrote:
Apparently the non blocking changes are only specified in trunk.
And the non-blocking changes in the core output filter, AFAIK, are
still busted. We need to either complete those changes or revert
them. -- justin
On 11/8/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
+1 for this if it is a subproject like mod_perl or mod_python. It may
go into the core or not in the future, but I think its dependency on
libapreq2 which is *currently* not part of the core makes it impossible
at the *current* point of time t
On 11/12/06, Paul Querna <[EMAIL PROTECTED]> wrote:
This is a work-in-progress patch, integrating CLuence[1] as a full text
search engine for mod_mbox.
+1 (concept). Since lucene4c isn't going anywhere soon, it makes
sense to look at other integration avenues.
Bonus points if you remove the s
On 11/12/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
> FWIW, mod_mbox, which you listed as dormant, has had more commits
> in the last 6 months than the 1.3.x branch.
BFD, when was the last time people reviewed them? When did it release?
I am more than happy to change the status when the sta
On 11/12/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
|-- mod_python(active, four committers)
It's probably time to spin off mod_python to its own TLP. They've
survived Grisha's (temporary) departure and they're making forward
progress. I'll volunteer to continue watching
On Sun, Nov 26, 2006 at 07:37:59PM -0800, Paul Querna wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> This is a vote to import mod_wombat under the httpd pmc.
+1.
BTW, IMO, the number of ninnies who want to force us to vote multiple times is
getting really annoying. -- justin
On 11/28/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
Actually as posted to apr - later today if nobody screams (waiting mostly
to make sure the other projects haven't noticed any glaring flaws - we now
answer to stdcxx, the native-internal tomcat connectors, svn etc. APR seems
to continu
On 12/6/06, Joe Orton <[EMAIL PROTECTED]> wrote:
The motivation given by the submitter was that he pays per byte served,
it seems entirely reasonable to allow the Server header to be disabled
for such users.
And he has the code. If it's that important, he can change the code.
(Wanna bet he doe
On 12/6/06, Chris Darroch <[EMAIL PROTECTED]> wrote:
Hi --
The short version of this email is, please, can people review
this patch for server/request.c and see if it breaks anything?
There are versions for trunk and 2.2.x. Thanks in advance!
http://people.apache.org/~chrisd/patches/walk_ca
On 12/6/06, Jeff Trawick <[EMAIL PROTECTED]> wrote:
We're up to two great answers to disable some output from the server
that isn't required by the HTTP protocol anyway:
1) modify the source
2) install third-party module
So, uh, why do we need to make it even easier for them? -- justin
On 12/6/06, Frank <[EMAIL PROTECTED]> wrote:
My question is: How does this interfere with my module? How can I ensure
that only one of us (mod_ssl or my module) is calling these both
functions? I cannot believe that there is no problem when my module
You just can't. I wish there was a better a
On 12/6/06, Nick Kew <[EMAIL PROTECTED]> wrote:
A corresponding authz hook will implement a "Require inherit"
to enable subrequests with "inherited" set to be authorized,
and will run ahead of "normal" authz hooks.
Would that be a good solution here?
I think you mean that if they have 'require
On 12/7/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
Entities gzip:ed by mod_deflate still carries the same ETag as the
plain entiy,
causing inconsistency in ETag aware proxy caches.
I'll have a look later and see if I can fix it, but let me know if there
is already a patch in the works (that
On 12/7/06, Justin Erenkrantz <[EMAIL PROTECTED]> wrote:
mod_deflate should just add the W/ prefix if it's not already there. -- justin
But, that'll break caches as we're not allowed to serve If-Match with
weak entity tags. Feh.
-1 on adding semantic junk to the exist
On 12/8/06, Henrik Nordstrom <[EMAIL PROTECTED]> wrote:
No, that won't work. You still be just as non-conforming by doing that.
But if mod_deflate may to produce different octet-level results on
different requests for the same original entity then it must do this in
addition to other transforms o
On 12/8/06, Henrik Nordstrom <[EMAIL PROTECTED]> wrote:
The protocol is quite fine as it is, and not easy to change. As it is
now it's mainly a matter of understanding that mod_deflate does create a
completely new entity from the original one. To the protocol it's
exactly the same as when using m
On 12/8/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
What we should be doing is sending transfer-encoding, not content-
encoding,
and get past the chicken and egg dilemma of that feature in HTTP.
If we are changing content-encoding, then we must behave as if there
are two different "files" on t
On 12/8/06, Henrik Nordstrom <[EMAIL PROTECTED]> wrote:
A strong ETag must be unique among all variants of a given URI, that is
all different forms of entities that may reside under the URI and all
their past and future versions.
A weak ETag may be shared by two variants/versions if and only if
On 12/9/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
> The existing filter needs to modify the ETag field value (and
> any other entity-dependent values that we can think of) or be
> removed as a feature. Weak etags are not a solution -- being able
> to make range requests of large cached repre
On 12/9/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
The best solution is to not mess with content-encoding at all, which
gets us out of both this consistency problem and related problems
with the entity-header fields (content-md5, signatures, etc.).
That is why transfer encoding was invented i
On 12/9/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
Thanks for giving the pointer to ap_meets_conditions. So content compressed
by mod_deflate would not stand conditional requests based on ETags any longer.
That would be bad. Would it help if we simply unset the ETag in mod_deflate?
mod_filter
On 12/15/06, Jim Jagielski <[EMAIL PROTECTED]> wrote:
I see your point 100% though... I really hoped that we would
have had a 2.2.4 out sooner, but the votes didn't come as
fast as expected :)
What votes? I haven't seen any votes for 2.2.4. -- justin
On 10/18/06, Trent Nelson <[EMAIL PROTECTED]> wrote:
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 11 October 2006 05:31
> To: [EMAIL PROTECTED]
> Subject: svn commit: r462696 - in /httpd/httpd/trunk: CHANGES
> modules/cache/mod_disk_cache.c modules/cach
On 12/25/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
Just so folks are aware why...
>> > +APU_DECLARE_DATA const apr_bucket_type_t bucket_type_diskcache = {
>> > +"DISKCACHE", 5, APR_BUCKET_DATA,
>> > +diskcache_bucket_destroy,
>> > +diskcache_bucket_read,
>> > +diskcache
On 12/26/06, Brandon Fosdick <[EMAIL PROTECTED]> wrote:
Does gdb work on httpd and FreeBSD yet? I remember seeing some action on that
front many moons ago, but I don't remember what came of it.
gdb 6.6 works okay from source on FreeBSD 6.1. But, gdb 6.1 (bundled
with FreeBSD 6.1) certainly do
On 12/26/06, Brandon Fosdick <[EMAIL PROTECTED]> wrote:
Did you build 6.6 by modifying the 6.5 skeleton (from the PR) or did you build
it straight from source?
FWIW, I built straight from source and it worked fine. -- justin
On 12/29/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
Propchange: httpd/test/trunk/flood/flood.vcproj
--
svn:eol-style = CRLF
-1.
My understanding was that VC 2005 requires its project files to be
CRLF-delim
On 12/29/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
"Partial results are valid but processing is incomplete" seems to be the OS
error message
to me. To be honest I am not quite sure what it wants me to tell. On which OS
did this happen?
I believe that error string is the APR_INCOMPLETE des
On 12/29/06, Chris Darroch <[EMAIL PROTECTED]> wrote:
The main trick here is that instead of the hard-coded version
string "0" for authn/z providers, AUTHN/Z_PROVIDER_VERSION_ALL_REQ and
AUTHN/Z_PROVIDER_VERSION_INITIAL_REQ are defined.
Without looking at the code, I'd hope that means that t
On 12/30/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
Digging somewhat deeper it turns out that adding APR_FINFO_NAME to the list of
wanted
information causes this apr_stat to return always APR_INCOMPLETE on Unix
platforms in
the case that the call to the native stat / lstat does not fail. Thi
On 12/30/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
Done in r491297 and hopefully documented well enough.
Pushed out a new build and now http://archive.apache.org/ is fine.
Thanks! -- justin
On 1/2/07, "Torben S. Sørensen" <[EMAIL PROTECTED]> wrote:
I'm trying to build flood according to the instructions on the
http://httpd.apache.org/test/flood/building.html. The source is version
0.4 and I'm building it on a Ubuntu 6.10 system.
As you can se on in the bottom I get an error very ea
On Tue, Jan 09, 2007 at 12:09:17AM -0600, William A. Rowe, Jr. wrote:
> Before I go any further, httpd-2.2.4-win32-src.zip is updated here at 6am UT
> and will take an hour to move across to the live site
>
> http://httpd.apache.org/dev/dist/
>
> while the .tar files remain unchanged. Feedback
301 - 400 of 1417 matches
Mail list logo
