On Dec 6, 2004, at 7:53 PM, Paul Querna wrote:
I do not agree that using writev() would allow multiple children from
scribbling over each other's log entries. I have not been able to
cause this to happen on my local machines.
You might want to consider what happens on all of the not so recent
o
On Dec 6, 2004, at 5:28 PM, Cliff Woolley wrote:
On Mon, 6 Dec 2004, William A. Rowe, Jr. wrote:
Same location as mod_log_forensic? If you want to move them
both into a modules/debug/ location, ++1.
mod_bucketeer would be classified as a debugging module, also. It's
currently under modules/test.
> Just a reminder to make sure this doesn't fall off the radar ;-)
yeah, sorry about that. call it day job encroachment :)
here's a patch against current HEAD (trunk?). I'll give it a day or two to
marinate and commit before the week is out if there are no complaints.
fwiw, the perl-framework
On Mon, 6 Dec 2004, Paul Querna wrote:
> Having looked at the writev() implementation in FreeBSD 5.2, it will
Not all platforms have writev(). I hope we stil have that APR flag
for that ?!
Dw
On Dec 7, 2004, at 6:04 AM, Jim Jagielski wrote:
On Dec 6, 2004, at 5:28 PM, Cliff Woolley wrote:
On Mon, 6 Dec 2004, William A. Rowe, Jr. wrote:
Same location as mod_log_forensic? If you want to move them
both into a modules/debug/ location, ++1.
mod_bucketeer would be classified as a debugging m
I did a module like mod_dumpio, called mod_log_data, working with
brigade and bucket, where you can setup number of brigade and bucket to
display, len of log line, and also dump outgoing and incoming headers.
It has been added in freebsd ports, and in some linux distrib. If you
are interested to
On Tue, 7 Dec 2004, Jim Jagielski wrote:
> On Dec 6, 2004, at 5:28 PM, Cliff Woolley wrote:
> > On Mon, 6 Dec 2004, William A. Rowe, Jr. wrote:
> >> Same location as mod_log_forensic? If you want to move them
> >> both into a modules/debug/ location, ++1.
> >
> > mod_bucketeer would be classified
It appears that the patch for bug 18757 which disallows a
content-length header for all requests with a content-length of 0 is too
broad.
Index: D:/Projects/2.x/httpd-trunk/server/protocol.c
===
--- D:/Projects/2.x/httpd-trunk/ser
On Tue, Dec 07, 2004 at 10:14:28AM -0700, Brad Nicholes wrote:
> It appears that the patch for bug 18757 which disallows a
> content-length header for all requests with a content-length of 0 is too
> broad.
...
>
> The bug simply says that the content-length should be removed just for
> HEAD r
>I tested the TLS upgrade stuff last week and it failed because the
>zero-length chunk to terminate the OPTIONS response was not sent
through
>the mod_ssl output filter; is that the same problem you see?
I don't think so. I can make everything work again by simply allowing
the "Content-Length: 0"
This patch also looks bogus given the fact that the content-length
header for a r->header_only request is already being handled in
ap_http_header_filter(). Removing all Content-Length: 0 headers in the
ap_content_length_filter() seems like overkill.
Brad
>>> [EMAIL PROTECTED] Tuesday, Decembe
On Tue, Dec 07, 2004 at 11:01:13AM -0700, Brad Nicholes wrote:
> >I tested the TLS upgrade stuff last week and it failed because the
> >zero-length chunk to terminate the OPTIONS response was not sent
> through
> >the mod_ssl output filter; is that the same problem you see?
>
> I don't think so.
After days end days of debugging the undebuggable (=autoshit),
i've found out, that configure doens't recognize my GNU ld as an
GNU ld and so disables shared libraries silently.
This ended up in libtool generating only static libraries instead
of shared objects.
Passing --with-gnu-ld didn't have
Hi folks,
here's a patch against httpd-2.0.49 which fixes the broken
configure script. I'm happy enough that I now have at least *one*
working version and I'm relly too lazy to go in deeper autoconf
torture, so the one who's responsible for ./configure should
fix it all versions.
Life could be
So what are you suggesting that the appropriate fix should be? Even
though the protocol.c patch was bogus, it sounds like might have exposed
something else. In fact I am still not seeing where the problem is.
The protocol.c patch was just allowing a bad response to happen that
should never ha
On Tue, Dec 07, 2004 at 03:00:52PM -0700, Brad Nicholes wrote:
>So what are you suggesting that the appropriate fix should be? Even
> though the protocol.c patch was bogus, it sounds like might have exposed
> something else. In fact I am still not seeing where the problem is.
Try doing an u
OK, now that you have enabled upgrades for anything other than
OPTIONS, I see the problem. Even though there is a content-length
included in the header, you are saying that the header is being sent
encrypted but the content is not, correct? And the reason for this is
because there is more than
17 matches
Mail list logo
