(This is a repost. My original context diffs from August 23 won't
apply cleanly to the current code base (due to changes in some adjacent
code), so I've generated this new patch against the latest version of
mod_include.c in CVS.)
--Brian
Index: modules/filters/mod_include.c
===
On Sat, Sep 01, 2001 at 06:19:32PM -0700, Ryan Bloom wrote:
> On Saturday 01 September 2001 14:56, Justin Erenkrantz wrote:
>
> I have a few problems with this. 1) We have consistantly declined to
> accept the mod_Gzip from remote communications.
mod_gzip implements the gzip algorithm. It als
On Saturday 01 September 2001 21:56, Rodent of Unusual Size wrote:
> On 2001-09-01 at 18h19, possibly To [EMAIL PROTECTED] et al.,
>
> the keyboard of "Ryan Bloom" chattered:
> > 3) I don't believe that we
> > should be adding every possible module to the core distribution. I
> > personally thin
On 2001-09-01 at 20h50, possibly To [EMAIL PROTECTED] et al.,
the keyboard of "Ryan Bloom" chattered:
>
> Putting every module into the core is NOT the answer to this problem.
True.
> IMNSHO, Apache should be a minamilistic web server.
IMNSHO, strong disagreement. It should be able to be conf
On 2001-09-01 at 18h19, possibly To [EMAIL PROTECTED] et al.,
the keyboard of "Ryan Bloom" chattered:
>
> 3) I don't believe that we
> should be adding every possible module to the core distribution. I
> personally think we should leave the core as minimal as possible, and
> only add more modul
Ryan et al,
I don't want to start another firestorm of issues. Mod_gzip has and is
working well for Apache 1.x users. It supports both static and dynamic
content and there are even some hacks to support compressed SSL. It's
entirely configurable and you can easily disable problematical browsers.
On Saturday 01 September 2001 20:10, Cliff Woolley wrote:
> Taking a step back from gz for a moment, and speaking in general:
>
> On Sat, 1 Sep 2001, Ian Holsman wrote:
> > 3rd party modules are invisible to most people,
>
> I'll agree with that statement... we can tell ourselves that it's okay to
> You know what's really funny? Every time this has been brought up before,
> the Apache core has always said, if you want to have gzip'ed data, then
> gzip it when you create the site. That way, your computer doesn't have to
> waste cycles while it is trying hard to serve requests. I personall
Ryan Bloom wrote:
>
> You know what's really funny? Every time this has been brought up before,
> the Apache core has always said, if you want to have gzip'ed data, then
> gzip it when you create the site. That way, your computer doesn't have to
> waste cycles while it is trying hard to serve r
Taking a step back from gz for a moment, and speaking in general:
On Sat, 1 Sep 2001, Ian Holsman wrote:
> 3rd party modules are invisible to most people,
I'll agree with that statement... we can tell ourselves that it's okay to
push off modules onto third-party distribution, but the fact is
Peter J. Cranstone wrote:
> Just a heads up for this forum. We have finished porting mod_gzip to
> Apace 2.0 but are holding off on releasing it until Apache goes solid
> beta. There are still a lot of unresolved issues and would rather see
> the 2.x more stable before releasing.
>
> Mod_gzip fo
On Sat, 1 Sep 2001, Ryan Bloom wrote:
> Their code has always been open source. Their 1.3 code is basically
> based on code from Krow at /.
I know that. But the 2.0 version is supposed to be vastly different
(less complex) than the 1.3 version, from what I remember. I'd just like
to see it.
On Thursday 30 August 2001 11:49, William A. Rowe, Jr. wrote:
Looking at this right now. :-)
Ryan
> Would someone be willing to review, patch, and close this PR?
>
> Bill
>
> - Original Message -
> From: "Taketo Kabe" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, July
On Saturday 01 September 2001 18:53, Cliff Woolley wrote:
> On Sat, 1 Sep 2001, Ryan Bloom wrote:
> > On Saturday 01 September 2001 14:56, Justin Erenkrantz wrote:
> >
> > I have a few problems with this. 1) We have consistantly declined to
> > accept the mod_Gzip from remote communications.
>
>
From: "Pier Fumagalli" <[EMAIL PROTECTED]>
Sent: Saturday, September 01, 2001 8:57 PM
> "Ryan Bloom" <[EMAIL PROTECTED]> wrote:
> >
> > 3) I don't believe that we should be adding every possible module to the core
> > distribution. I personally think we should leave the core as minimal as
> >
"Ryan Bloom" <[EMAIL PROTECTED]> wrote:
>
> 3) I don't believe that we should be adding every possible module to the core
> distribution. I personally think we should leave the core as minimal as
> possible, and only add more modules if they implement a part of the HTTP spec.
I can't say much,
On Sat, 1 Sep 2001, Ryan Bloom wrote:
> On Saturday 01 September 2001 14:56, Justin Erenkrantz wrote:
>
> I have a few problems with this. 1) We have consistantly declined to
> accept the mod_Gzip from remote communications.
That's true, though that was for 1.3. Just now with Peter's message
Just a heads up for this forum. We have finished porting mod_gzip to
Apace 2.0 but are holding off on releasing it until Apache goes solid
beta. There are still a lot of unresolved issues and would rather see
the 2.x more stable before releasing.
Mod_gzip for Apache 2.0 is based on mod_gzip for A
On Saturday 01 September 2001 14:56, Justin Erenkrantz wrote:
I have a few problems with this. 1) We have consistantly declined to
accept the mod_Gzip from remote communications. 2) I keep hearing that
zlib has more memory leaks than a sieve. 3) I don't believe that we
should be adding ever
On 2 Sep 2001 [EMAIL PROTECTED] wrote:
> jerenkrantz01/09/01 18:09:02
>
> Modified:.CHANGES
>modules/filters mod_include.c mod_include.h
> Log:
> Make mod_include check for BYTE_COUNT_THRESHOLD on a per-bucket basis
> rather than on a per-character basis.
On Tue, Aug 28, 2001 at 09:48:05PM -0700, Brian Pane wrote:
> Thanks to everybody who reviewed the first patch. This new
> version adds error-checking fixes and moves the brigade-splitting
> back into send_parsed_content. I also added a nonblocking read
> to find_end_sequence.
Committed. Thank
Just compiled httpd 2.0 off CVS and I have a small problem with the GNU
libtool included with OS/X 10.0.4 and the latest developers CD... It doesn't
link libraries in the right way (dunno still if it's actually LibTool, or
Darwin's LD)... Example...
./httpd -l
dyld: ./httpd can't open library: .l
On Sat, 1 Sep 2001, Ian Holsman wrote:
> the perl-framework is complaining about some CGI tests failing.
> but I seem to remember that this was a problem with the test itself.
The CGI test works fine for me with mod_cgi/prefork (I think I tried it
with mod_cgid/threaded also, but not positive) a
On Sat, 1 Sep 2001, Justin Erenkrantz wrote:
> On Sat, Sep 01, 2001 at 02:34:13PM -0700, Ryan Bloom wrote:
>
> > I would personally rather see us spend a week or two and get this
> > stuff done right and then roll 2.0.26, than keep hacking this to
> > pieces. I think we are far better off taking
Ian has posted his mod_gz filter before, now I'd like to give it a +1.
I told him I'd look at it a while ago, but never got a chance to do
so. So, I spent this morning cleaning up the configuration and a bit
of the code to fit our style (nothing major).
I'd like to add this to the modules/fil
On Sat, Sep 01, 2001 at 02:34:13PM -0700, Ryan Bloom wrote:
> On Saturday 01 September 2001 13:57, Cliff Woolley wrote:
>
> I would personally rather see us spend a week or two and get this stuff done
> right and then roll 2.0.26, than keep hacking this to pieces. I think we are
> far better off
On Saturday 01 September 2001 13:57, Cliff Woolley wrote:
I would personally rather see us spend a week or two and get this stuff done
right and then roll 2.0.26, than keep hacking this to pieces. I think we are
far better off taking a deep breath, finishing this work cleanly, and then
moving fo
Cliff Woolley wrote:
> AFAICT, there is only one remaining showstopper problem with 2.0.26-dev,
> which is that subrequests for relative paths in other directories (ones
> that result in r->uri being that "INTERNALLY GENERATED" thing) often cause
> a segfault (mod_include exhibits this problem wh
AFAICT, there is only one remaining showstopper problem with 2.0.26-dev,
which is that subrequests for relative paths in other directories (ones
that result in r->uri being that "INTERNALLY GENERATED" thing) often cause
a segfault (mod_include exhibits this problem when doing includes of files
in
Graham Leggett 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 b
On Saturday 01 September 2001 11:20, Graham Leggett wrote:
> Ryan Bloom wrote:
> > > The core question is whether we store data in the cache with transfer
> > > encodings already applied.
> >
> > I would put it before the content encodings, but after the content
> > filters. My reasoning is simpl
2.0.25-alpha from http://dev.apache.org/dist
"William A. Rowe, Jr." wrote:
>
> Tonight's tree? Ugh. Send it at the list - I'm sure we are doing -one-
> too many steps with our security overhaul :(
>
> - Original Message -
> From: "Jerry Baker" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECT
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 directi
Ryan Bloom wrote:
> > The core question is whether we store data in the cache with transfer
> > encodings already applied.
>
> I would put it before the content encodings, but after the content filters. My
> reasoning is simple. Content encodings tend to be fast, but content filtering
> tends
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
On Saturday 01 September 2001 05:51, Graham Leggett wrote:
> Ryan Bloom wrote:
> > My own opinion is that the cache should be the last content filter run.
> > Basically, it should probably be specified as the first HTTP_HEADER
> > filter type.
>
> The core question is whether we store data in the
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
Ryan Bloom wrote:
> My own opinion is that the cache should be the last content filter run. Basically,
> it should probably be specified as the first HTTP_HEADER filter type.
The core question is whether we store data in the cache with transfer
encodings already applied.
Regards,
Graham
--
--
Bill Stoddard wrote:
> I'm a bit fuzzy on how to run the GZIP filter from CACHE_IN but I assume something
>clean
> can be done. Detecting if the client supports unzip and conditionally installing
>GUNZIP is
> simple and should just work without resorting to anything unnatural.
The cache_storag
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.
If mod_includes needs
40 matches
Mail list logo
