that we know will survive clearing the request_rec.
[Ryan Bloom, Justin Erenkrantz [EMAIL PROTECTED],
Cliff Woolley]
--
Sunitha Kumar
http://www.cisco.com
--
Greg Stein, http://www.lyra.org/
.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
A society that will trade a little liberty for a little order
will lose both and deserve neither
--
Greg Stein, http://www.lyra.org/
. That isn't part of httpd-2.0 so why
is the config in there?
proxy.conf is a whole 20 lines or so. Splitting that out is just a damned
pain in the butt.
Please explain... this just doesn't seem right at all. Multiple configs are
nasty nasty nasty.
-g
--
Greg Stein, http://www.lyra.org/
return an EOS; you could also
return N bytes plus an EOS)
The non-blocking mode could return a zero length brigade.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
);
--
Greg Stein, http://www.lyra.org/
it
doesn't get installed there). That's the whole point.
Um... gotta ask Ken about this. He vetoed a change in this area.
If the change related to the veto hasn't been backed out, then we may have
to yank 1.3.21
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
optimizing for
return a nice amount.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
and saying take the next two steps
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
was asked and no more.
But I seriously doubt that is the problem here. I'm guessing that mod_ssl
was coded knowing that the brigade it got back from f-next was a socket
bucket. Or that the brigade had certain properties when reading from it.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
filters said that
somebody *could* do that, but it just didn't happen.
Can you say, fragile ? Thought so.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
(str, APR_ASCII_LF, len);
How about a new brigade function first?
I don't know much about the rest of how this filter works, but I am
seriously suspicious of the removal of the renegotiation code.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
--
Greg Stein, http://www.lyra.org/
Well said.
I can happily contribute knowledge, but am so backed up on various projects
that helping with coding just falls further and further behind. (sigh)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
saying that people won't have every
third party module, so each apache process would have *huge* holes, thus
wasting significant processor tables ]
Does that answer your questions? :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
query; I'm not sure that we'd rip it
out (there could still be people who don't regularly read this list); I
think the answer is to fix Configure to find the system lib when possible.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
/experimental/mod_ext_filter
That experimental in there means just that :-) ... it could be updated if
somebody wants to. Or it could remain the same... :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
, and
that two people are fine with the patch, then it can/should go in. If
further problems are discovered in the patch, then they can be fixed in the
repository rather than before the patch is applied.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
with adding the HTTP_IN filter.
If somebody wants to make protocol.c pure, then they're going to have a
lot more to worry about than the HTTP_IN thing.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Mon, Oct 01, 2001 at 03:51:07PM -, [EMAIL PROTECTED] wrote:
wrowe 01/10/01 08:51:07
Modified:modules/generators mod_status.c
Log:
Clean up some warnings by summing bytecounts into apr_off_t holders
instead of ulongs.
Ah! Good stuff.
Cheers,
-g
--
Greg Stein
message -
--
Greg Stein, http://www.lyra.org/
having fun yet? :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
(from before Justin's
patch, and at least one new one). I tried to comment the hacks before;
thankfully, Justin's patch removes most of those. But there are still more,
and we can't just let those slide...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
win. [unless apr-client somehow managed to stabilize really fast]
I just think that the ASF projects could use it, and I think getting a
nicely licensed, fully capable client library would be great.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Wed, Sep 26, 2001 at 03:33:12PM -0700, Justin Erenkrantz wrote:
On Wed, Sep 26, 2001 at 03:21:42PM -0700, Greg Stein wrote:
But that said, I'm am a BIG +1 on adding an http client library into the
ASF's APR project. Whether people want that to go into apr-util or into a
new apr-client
On Thu, Sep 27, 2001 at 01:33:10AM +0200, Graham Leggett wrote:
[EMAIL PROTECTED] wrote:
add the ProxyHTTPOverrideReturnedErrors directive documentation
Would anyone object to me changing this to ProxyErrorOverride - the
above directive is *way* too long...
+1
--
Greg Stein, http
On Sun, Sep 23, 2001 at 09:27:58PM -0700, Ryan Bloom wrote:
On Sunday 23 September 2001 09:21 pm, Greg Stein wrote:
...
There is a create_request hook which inserts the HTTP_IN filter when the
request is created.
This seems like a good idea: each instantiation of the HTTP_IN filter
--
Greg Stein, http://www.lyra.org/
don't have the apr_brigade_to_buffer
function for now.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Mon, Sep 24, 2001 at 11:58:40AM -0700, Justin Erenkrantz wrote:
On Mon, Sep 24, 2001 at 01:32:02AM -0700, Greg Stein wrote:
Eww. No... just move the filter back to the connection and you're fine. We
can make it a request filter later on.
Actually, you can't make it a connection-based
. We've got architecture issues with
input filtering. And that is just one piece of the code.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
. While some people may argue that isn't the
best thing for the code, it *is* the best thing for the group and the
community. And (IMO) that is at least as important as the code, if not more.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
change to http_protocol.c makes that hard to review. Other notes may be
coming soon...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Sun, Sep 23, 2001 at 03:04:54PM -0700, Ryan Bloom wrote:
On Sunday 23 September 2001 02:53 pm, Greg Stein wrote:
On Sun, Sep 23, 2001 at 08:33:07AM -0700, Ryan Bloom wrote:
None of this can be committed until it has passed all of the tests in the
perl test framework. The last time
to a mod_mbox page and view the source...)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
that, then
it could just calll B. But the most important part: all cleanups *do* get
run.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Thu, Sep 20, 2001 at 07:02:58AM -0700, Ryan Bloom wrote:
On Wednesday 19 September 2001 02:21 pm, Greg Stein wrote:
...
They are not strictly LIFO. You can remove a cleanup and insert a new one
at any time. Let's say that the cleanup list looked like:
cleanups: A
and you add
, a discarded value isn't a Good Thing, so those (void) casts
leave markers for somebody to fix the code at some future time.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Tue, Sep 18, 2001 at 06:33:14PM -0700, Aaron Bannert wrote:
On Tue, Sep 18, 2001 at 06:01:35PM -0700, Greg Stein wrote:
...
...
--- fdqueue.c 2001/09/18 21:14:18 1.6
+++ fdqueue.c 2001/09/18 23:09:12 1.7
@@ -73,7 +73,6 @@
*/
static int ap_queue_empty
On Wed, Sep 19, 2001 at 01:52:12PM -0400, Rodent of Unusual Size wrote:
Greg Stein wrote:
It isn't a bug. Cleanups are for just wrapping things up,
not doing work.
If that's the authoritative answer, then we need to provide
a supported way for 'doing work' at cleanup time.
You might
On Wed, Sep 19, 2001 at 12:16:24PM -0700, Ryan Bloom wrote:
On Wednesday 19 September 2001 11:37 am, William A. Rowe, Jr. wrote:
From: Greg Stein [EMAIL PROTECTED]
Sent: Wednesday, September 19, 2001 1:26 PM
...
The problem is cross-dependency between the cleanup actions. One can
-httpd-2.x.x.tar.gz seems better.
Agreed.
I am +0 on httpd-2... and +1 on apache-httpd-2...
btw, no dates in those either (a suggestion from otherbill). The version
number tells us what we need to know.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
.
And all your spoofy nonsense can stay in your module, but it can't go in the
core. That would just be too hard to understand and maintain over the long
haul.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
--
Greg Stein, http://www.lyra.org/
into apache-modules-2.x.x.tar.gz.
+1
--
Greg Stein, http://www.lyra.org/
a
new tag since it involves API changes, but I guess it's not a showstopper.
Apache's prefork MPM seems to be having problems with persistent
connections. They've been dogging some of my testing and SVN. I'm gonna dig
into it this evening.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
of these or the default location set by the layout.
Not a problem, I think.
If the hard-coded default is never used, then why don't we just toss it, and
require people to pass/use a root?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
. Using Location / fixes that.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Thu, Sep 13, 2001 at 09:35:43AM -0700, dean gaudet wrote:
On Tue, 11 Sep 2001, Greg Stein wrote:
...
Seems that we now have 64 bit cpu's with potentially 64 bit pids. This adds
to the equation, it looks like we need to cut over to those extra four bytes
across all platforms.
Oh
pid = getpid();
#endif
On the other side I saw that some other sources inside Apache use getpid(), is this
not a problem there too? And if only Win32 has an insufficient getpid() definition,
it may be enough to redefine this only there and leave all other as is...??
Guenter.
--
Greg
to deal with the rollup
anyways, which would totally kill any impetus for putting proxy back in.
thus, I'm against bringing proxy back into the core. ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
-length:' if/when it is necessary.
All good points. There are also a bazillion other things that mod_gzip 1.x
does, which mod_gz can't do (and you've explained that it should). That work
can be done with the module placed into the experimental directory.
Cheers,
-g
--
Greg Stein, http
could transparently decompress for the user)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
can do rollup releases. Once
we have that framework in place, then something like -extras could make
sense.
But any use of repositories outside of httpd-2.0 is going to simply make our
existing rollup problem even worse.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
you say placeholder, are you suggesting that you're going to commit the
code back into the httpd-2.0 branch?
Rather than doing that, why don't we work on the rollup mechanism instead?
Proxy has been moving along terrifically while in its own CVS module.
Cheers,
-g
--
Greg Stein, http
with it. It is really difficult to do that while it is a
patch being maintained by a single person.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
people have different but equally valid
opinions. No one person sets an absolute for the project.
Well, until they whip out their veto pen :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
with basic auth, but forgot
that another URL can access the same directory.)
If you wanted to add a URLMapTo directive that does something similar, I
would be less opposed. But I still would not be in favour.
Joshua.
--
Greg Stein, http://www.lyra.org/
pattern for multiple/rollup releases
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
other than
email address distribution.
--
Greg Stein, http://www.lyra.org/
On Wed, Sep 05, 2001 at 03:56:32AM -0400, [EMAIL PROTECTED] wrote:
Greg Stein wrote...
...
As stated elsewhere, pcre and expat are in there because they aren't
typically available, like zlib is.
Ah... so that's the criteria? Ok.
Generally, yes. But size matters :-) OpenSSL 0.9.6 isn't
can use the machine's most optimal path. But I'd ask if strstr() isn't
optimized on the platform, why are we reinventing it?
strstr() can't find strings that span a bucket boundary.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
with GZ, but have a lower deviation
The expectation is that the network bandwidth used should be much
lower. The tradeoff is that the CPU should get nailed. -- justin
Also: latency should increase and delivery time should decrease.
cheers,
-g
--
Greg Stein, http://www.lyra.org/
, then that is
their own fault, not the fault of introducing a new module.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Wed, Sep 05, 2001 at 09:15:56PM -0700, Ian Holsman wrote:
Greg Stein wrote:
On Wed, Sep 05, 2001 at 08:05:27PM -0700, Ian Holsman wrote:
Some performance results with mod_gz are available at
http://webperf.org/a2/v25/
(no core dumps.. pages look ok on a real browser while running test
that... :-)
Committed. Thanks. -- justin
eek.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Tue, Sep 04, 2001 at 08:15:08AM -0700, Ryan Bloom wrote:
On Sunday 02 September 2001 01:22, Greg Stein wrote:
...
I use distclean on my computer all the time. Along with extraclean. Neither
of those targets should toss config.nice. *That* is what I mean.
To be clear: nothing in our
,
-g
--
Greg Stein, http://www.lyra.org/
rather than later, and we
will deal with any API changes that occur between now and ship -- it isn't
your burden to bear, so there shouldn't be a reason to withold.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
of ASF-distributed bits? etc.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
explained my reasons, Cliff and Justin seem to
agree quite wholeheartedly. And I'll repeat: -1 on anything rm'ing
config.nice
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
of filter execution isn't going to be
right given the code we have now. -- justin
--
Greg Stein, http://www.lyra.org/
On Fri, Aug 31, 2001 at 09:16:15PM -0700, Ryan Bloom wrote:
On Friday 31 August 2001 19:31, William A. Rowe, Jr. wrote:
From: Greg Stein [EMAIL PROTECTED]
Sent: Friday, August 31, 2001 9:30 PM
On Fri, Aug 31, 2001 at 03:02:32PM -0700, Ryan Bloom wrote:
...
exports.c shouldn't
really confusing to see -1 and never
know what it means. As I've said before: -1 really ought to always mean a
veto. But... that's just me :-)
Needless to say, I'm +1 on the concept. It's a big win for everybody. I
haven't reviewed the code yet, so no commentary there.
Cheers,
-g
--
Greg Stein
to be there -- some kind of global
that each MPM had to deal with... that was ooky; this patch looks good)
--
Greg Stein, http://www.lyra.org/
.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
;
+unsigned char dns_resolved:1;
} uri_components;
Screw the bitfields. Just change all of them to plain old unsigned chars.
(and apr_byte_t in APR). There is no reason to be miserly with bits here.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
it, but that doesn't mean it should
stay there :-)
--
Greg Stein, http://www.lyra.org/
On Tue, Aug 28, 2001 at 01:01:11PM -0700, Ryan Bloom wrote:
On Tuesday 28 August 2001 12:17, Greg Stein wrote:
On Mon, Aug 27, 2001 at 05:09:01PM -0700, Aaron Bannert wrote:
This patch implements a resource pool of context pools -- a queue of
...
IOW, why should this complexity be added
the following patch look correct? If so, I'll commit.
The SSI stuff is a handler in 1.3, so it is the proper guy to state what is
handled. And it says no POST :-)
As a filter in 2.0, mod_include should just stay out of it.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
with a lot of entropic
data. (i.e. where/how would it come from?)
But just a good PRNG function would be handy, I'd think.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
a particular protocol running over some socket to a
backend server. You know the next chunk of data is 1000 bytes. You insert
your custom socket bucket, saying this socket, 1000 bytes. It can be
read, but it can't be copied.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Fri, Aug 24, 2001 at 08:27:57AM -0700, Ryan Bloom wrote:
On Friday 24 August 2001 00:33, Greg Stein wrote:
On Fri, Aug 24, 2001 at 12:15:17AM -0700, Doug MacEachern wrote:
...
libuncooltool. i didn't realize libapr was now linked as a shared
library. that explains everything
On Wed, Aug 22, 2001 at 10:38:44PM -0700, Brian Pane wrote:
Greg Stein wrote:
...
Yes there is. apr_pool_userdata_set(..., r-pool)
...
Using the userdata functions on r-pool as a replacement for a
hash-based r-notes would be a mistake. The interface to the userdata
in a pool is limited
401 - 483 of 483 matches
Mail list logo
