On Thu, Aug 01, 2002 at 07:55:32PM -0400, Paul J. Reder wrote:
> This only addresses part of the headers. You aren't handling last_
> modified header value, the content_type or the filename (which are
> all handled in the mem_cache).
I believe the special elements in the request structure are fil
Not acked and obviously sent to the wrong address. -- justin
--- Begin Message ---
the htpasswd from the latest (as of an hour ago) snapshot runs fine from =
the command line, but does not run from a php script via the "exec" =
command.
exec("/usr/local/apache2/bin/htpasswd -b /data/secure/.me
This only addresses part of the headers. You aren't handling last_
modified header value, the content_type or the filename (which are
all handled in the mem_cache).
You also cut and pasted the offset value in your code.
+offset += (sizeof(info->expire)*2) + 1;
+info->request_time = ap_ca
On Thu, Aug 01, 2002 at 08:52:49AM -0400, Bill Stoddard wrote:
> mod_mem_cache fomr HEAD should work. mod_disk_cache is still broken.
>
> Try a config like this:
>
> LoadModule cache_module modules/mod_cache.so
>
>CacheOn On
> # CacheMaxExpire 2
> # CacheDefaultExpire 1
>LoadModule me
> > > Even if we don't build it, this is extremely good practice that
the
> folks
> > > rolling and releasing the tarball TAG the apr-iconv tree in sync
with
> > > the current apr and apr-util trees..
> >
> >I completely disagree. The problem is that the httpd_roll_release
> >script is for rolli
At 03:32 PM 8/1/2002, Ryan Bloom wrote:
> > From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]]
> >
> > At 11:42 AM 8/1/2002, you wrote:
> > >ianh2002/08/01 09:42:33
> > >
> > > Modified:buildhttpd_roll_release
> > > Log:
> > > we need apr-iconv now
> >
> > Even if we don't
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]]
>
> At 11:42 AM 8/1/2002, you wrote:
> >ianh2002/08/01 09:42:33
> >
> > Modified:buildhttpd_roll_release
> > Log:
> > we need apr-iconv now
>
> Even if we don't build it, this is extremely good practice that the
folks
At 11:42 AM 8/1/2002, you wrote:
>ianh2002/08/01 09:42:33
>
> Modified:buildhttpd_roll_release
> Log:
> we need apr-iconv now
Even if we don't build it, this is extremely good practice that the folks
rolling and releasing the tarball TAG the apr-iconv tree in sync with
the c
At 11:15 AM 8/1/2002, you wrote:
>Because there always seems to be one more person saying "ooh ooh wait for
>this one last thing" and the group is too afraid to do a dead-end branch.
Because they are time consuming, and wasteful?
The security incident we are discussing [which is not published] i
At 09:07 AM 8/1/2002, you wrote:
> > The workaround that I put in yesterday will suffice for most
> > installations, but we'll need to revert to the previous poll
> > code in order to have a GA-ready server once again.
>
>Then remind me again why we're having a .40 release? If the only crietria is
At 02:25 PM 8/1/2002, you wrote:
>On Thu, 1 Aug 2002, Sander Striker wrote:
>
> > > Is "apr-iconv" required now when building from CVS on Linux?
> >
> > No, only for win32 builds.
>
>For the record, I think it's a terrible idea to just sort of sneak this in
>there (in as much as it came to a huge
On Thursdayen den 1 August 2002 21.25, Cliff Woolley wrote:
> On Thu, 1 Aug 2002, Sander Striker wrote:
> > > Is "apr-iconv" required now when building from CVS on Linux?
> >
> > No, only for win32 builds.
>
> For the record, I think it's a terrible idea to just sort of sneak this in
> there (in a
On Thu, 1 Aug 2002, Sander Striker wrote:
> > Is "apr-iconv" required now when building from CVS on Linux?
>
> No, only for win32 builds.
For the record, I think it's a terrible idea to just sort of sneak this in
there (in as much as it came to a huge surprise to someone who hasn't been
able to
On Thu, 1 Aug 2002, Joshua Slive wrote:
> Personally, I have mixed feelings about this patch, which is why I haven't
> committed it myself. Yes, it does make the default config file more
> generally useful with different configurations. But it also makes the
> default config file less of a good
I am in the process of changing the docs build process so the build stuff
will no longer live in the httpd-2.0 tree. If you want docs builds to
work, don't update your tree for the next little while. When I am
finished, instructions for using the new system will be at
http://httpd.apache.org/doc
Graham Leggett wrote:
> Also the concept of "working on it" needs clarification. If the thing
> works as it stands, then there is no reason to commit anything to it.
> However some people have translated "no commits to the code" as meaning
> "noone is maintaining it", which I believe is wrong.
On Thu, 1 Aug 2002, Joshua Slive wrote:
> The default config file works with the default install. If you modify the
> default install, you also need to modify the default config. I'm
> comfortable with that. If you change the installed modules without
> modifying the default config files, you
On Thu, 1 Aug 2002, Tim Wilde wrote:
> I'm reposting the attached patch yet again, which adds various
> sections to the default httpd.conf to allow proper function without
> changes to httpd.conf if various modules aren't enabled. Sent this twice
> within the last two months now without any re
I'm reposting the attached patch yet again, which adds various
sections to the default httpd.conf to allow proper function without
changes to httpd.conf if various modules aren't enabled. Sent this twice
within the last two months now without any response. Makes me wonder if
anyone cares that t
On Thursdayen den 1 August 2002 19.16, Sander Striker wrote:
> > From: Oden Eriksson [mailto:[EMAIL PROTECTED]]
> > Sent: 01 August 2002 18:56
> >
> > Hi.
> >
> > Is "apr-iconv" required now when building from CVS on Linux?
>
> No, only for win32 builds.
Thanks, I suspected that but wasn't really
> From: Oden Eriksson [mailto:[EMAIL PROTECTED]]
> Sent: 01 August 2002 18:56
> Hi.
>
> Is "apr-iconv" required now when building from CVS on Linux?
No, only for win32 builds.
Sander
Oden Eriksson wrote:
> Hi.
>
> Is "apr-iconv" required now when building from CVS on Linux?
>
I think it is.
a simple
cvs co apr-iconv
in the srclib directory and re-running buildconf is all that is required
Hi.
Is "apr-iconv" required now when building from CVS on Linux?
--
Regards // Oden Eriksson
Deserve-IT Networks -> http://d-srv.com
On Thu, Aug 01, 2002 at 04:36:59PM +0100, David Reid wrote:
> OK, so a couple of people have replied off list that it's due to a security
> exploit. If that's the case then why haven't we done a .40 release before
> now?
Because there always seems to be one more person saying "ooh ooh wait for
th
Ugh, hate replying to my own emails, but hey sometimes you have to :(
OK, so a couple of people have replied off list that it's due to a security
exploit. If that's the case then why haven't we done a .40 release before
now? Either it's a security problem that warrants a release or it isn't.
Whic
>-- Original Message --
>Reply-To: [EMAIL PROTECTED]
>Date: Thu, 01 Aug 2002 16:59:08 +0200
>From: Graham Leggett <[EMAIL PROTECTED]>
>To: Brad Nicholes <[EMAIL PROTECTED]>
>CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
>Subject: Re: ldap
>
>
>I think the LDAP SSL stuff in the v1.3 module was largely b
Brad Nicholes wrote:
> Unless I missed
> it somewhere in the code, it seems that one of the pieces that got
> dropped on the floor when LDAP support was removed from APU was LDAP
> SSL.
I think the LDAP SSL stuff in the v1.3 module was largely based on some
LDAP client library specific #ifdef's
I am in total agreement. +1 for putting it into experimental. I guess
by saying "working on it" I do mean "maintaining it". Unless I missed
it somewhere in the code, it seems that one of the pieces that got
dropped on the floor when LDAP support was removed from APU was LDAP
SSL. This needs to
> The workaround that I put in yesterday will suffice for most
> installations, but we'll need to revert to the previous poll
> code in order to have a GA-ready server once again.
Then remind me again why we're having a .40 release? If the only crietria is
that it's been a while since the last on
Hi,
I have to develop an extension of the proxy module. This extension
must give some single sign-on functionnalities, and so, I try to
intercept authentification informations.
My problem is: I don't successful to log the information send by
a client after a form page (with POST method).
Martin Kutschker <[EMAIL PROTECTED]> writes:
> Date: 31 Jul 2002 12:12:47 -0400
> To: [EMAIL PROTECTED]
> From: Jeff Trawick <[EMAIL PROTECTED]>
> Subject: SSLMutex directive, PR 8122
> Message-ID: <[EMAIL PROTECTED]>
>
> > This PR points out a problem with the current SSLMutex handling in
> > m
> Brad Nicholes wrote:
>
> > So it seems like we burned all of our bridges. We had somebody
> > working on it until we added it in. Then the author stopped so we took
> > it out. Now we not only don't have anybody working on it, we also don't
> > have it.
>
> I don't think it's a case of noo
mod_mem_cache fomr HEAD should work. mod_disk_cache is still broken.
Try a config like this:
LoadModule cache_module modules/mod_cache.so
CacheOn On
# CacheMaxExpire 2
# CacheDefaultExpire 1
LoadModule mem_cache_module modules/mod_mem_cache.so
CacheEnable mem /
MCacheSiz
Brad Nicholes wrote:
> So it seems like we burned all of our bridges. We had somebody
> working on it until we added it in. Then the author stopped so we took
> it out. Now we not only don't have anybody working on it, we also don't
> have it.
I don't think it's a case of noone working on i
Brian Degenhardt wrote:
> 1) Make apache modules add apropriate headers to inform caches of the
>cacheability of objects.
What you're basically saying is "make all the modules in Apache be
correct with regard to Cache-Control headers", which is just another way
of saying "fix Apache where
35 matches
Mail list logo
