mod_info will tell you some of this. ie. Look for ScriptAlias lines under
mod_alias.c and AddHandler cgi-script lines under mod_mime.c.
But you are fighting a bit of a lost cause here. If you allow users to
upload arbitrary cgi scripts there really isn't much you can do at the
Apache level. It
In message <[EMAIL PROTECTED]>,
Zac Stevens <[EMAIL PROTECTED]> wrote:
>Let me preface this by noting that I agree with your goals, however I
>believe that you may not have considered the nature of the problem in
>sufficient depth.
I'll buy that. I mean it would be arrogant of me... and possi
On Thu, May 30, 2002 at 09:49:26PM -0400, Bill Stoddard wrote:
> And all that child's threads? If we are voting, I vote this is a showstopper. A
> segfaulting process can leave an awful lot of cruft laying around.
I would tend to agree, but as far as I know the segv has been fixed (and
the other
At 09:45 PM 5/30/2002, you wrote:
>I am directing this message to the developer's list because I strongly
>suspect that it may require some new development.
>...
>The first step in finding all such scripts however may often be the most
>difficult one. That first step consists of simply gathering
Hi Ronald,
Let me preface this by noting that I agree with your goals, however I
believe that you may not have considered the nature of the problem in
sufficient depth.
On Thu, May 30, 2002 at 07:45:42PM -0700, Ronald F. Guilmette wrote:
> Most sites and web hosting companies _do_ want to elimi
Greetings all,
I am directing this message to the developer's list because I strongly
suspect that it may require some new development.
I am working with many major web hosting companies to try to put a lid
on the FormMail spam problem. With regards to this it would be most
helpful if I could
> On Thu, May 30, 2002 at 11:17:23PM -, [EMAIL PROTECTED] wrote:
> > jerenkrantz02/05/30 16:17:23
> >
> > Modified:.STATUS
> > Log:
> > showstoppers++; (groan)
> >...
> >RELEASE SHOWSTOPPERS:
> > +
> > +* 413 (invalid chunk size) followed by another request
On Thu, May 30, 2002 at 05:29:26PM -0700, Justin Erenkrantz wrote:
> Per my earlier message, I believe this is the wrong way to do this.
>
> If we get a neg chunk length, we shouldn't *ever* get back into
> ap_http_filter (HTTP_IN). The whole point of the 413 error is
> that we refuse to read th
On Fri, May 31, 2002 at 12:23:34AM -, [EMAIL PROTECTED] wrote:
> aaron 02/05/30 17:23:34
>
> Modified:modules/http http_protocol.c
> Log:
> This fixes a failed assert when r->remaining is left in a negative
> state and we hit some other error (like permission failure) causin
On Thu, May 30, 2002 at 11:17:23PM -, Justin Erenkrantz wrote:
> +* 413 (invalid chunk size) followed by another request segfaults.
> + Message-ID: <[EMAIL PROTECTED]>
> + Status: Justin is completely confounded by this. It looks like a
> + bucket lifetime b
On Thu, May 30, 2002 at 11:02:09AM -0400, Jeff Trawick wrote:
> Running HEAD, we get a segfault when the bogus request is for a
> resource for which we aren't authorized. Here is the traceback:
In particular, this problem is related to the fact that we have
two errors on this request: 401 and 41
On Thu, May 30, 2002 at 11:17:23PM -, [EMAIL PROTECTED] wrote:
> jerenkrantz02/05/30 16:17:23
>
> Modified:.STATUS
> Log:
> showstoppers++; (groan)
>...
>RELEASE SHOWSTOPPERS:
> +
> +* 413 (invalid chunk size) followed by another request segfaults.
> +
On Wed, May 29, 2002 at 08:40:55PM -0400, Cliff Woolley wrote:
> On 30 May 2002 [EMAIL PROTECTED] wrote:
> > striker 02/05/29 17:21:27
> >
> > Modified:server/mpm/beos beos.c
> >server/mpm/experimental/leader leader.c
> >server/mpm/experimental/threadpool
On Thu, 30 May 2002, Greg Stein wrote:
> Personally, I'm finding that it seems we're getting back to the old, slow
> "it takes a lot of pain to make a release" process. Rather than a nice,
> easy, snap and release. Remember: even though we're GA, we can still snap
> new releases, test them, and *
On 30 May 2002 [EMAIL PROTECTED] wrote:
> -bb = apr_brigade_create(f->c->pool, f->c->bucket_alloc);
> +apr_brigade_cleanup(bb);
The old code could actually cause some problems. Some bucket types (eg
pool buckets) have cleanups that run. If the bucket is clea
On Thu, May 30, 2002 at 07:26:02PM -0400, Cliff Woolley wrote:
> On 30 May 2002 [EMAIL PROTECTED] wrote:
>
> > +
> > +* 413 (invalid chunk size) followed by another request segfaults.
> > + Message-ID: <[EMAIL PROTECTED]>
> > + Status: Justin is completely confounded by this
On Sun, May 26, 2002 at 11:24:49AM -0700, Brian Pane wrote:
>...
> I didn't yet cast a vote. So,
>-0 for including the pool fix in 2.0.37
>+1 for including it in 2.0.38.
Note: the real procedure here is that Sander gets to just check the stuff in
whenever he would like. (which, I believe
On 30 May 2002 [EMAIL PROTECTED] wrote:
> +
> +* 413 (invalid chunk size) followed by another request segfaults.
> + Message-ID: <[EMAIL PROTECTED]>
> + Status: Justin is completely confounded by this. It looks like a
> + bucket lifetime bug, but somehow an o
On Thu, 30 May 2002, Ryan Bloom wrote:
> Agreed, but I can think of one case. (a bit of hand-waving, but a
> possibility, nonetheless) :-) If I write two filters that work in
> tandem to solve a problem, I may want to use a special bucket type to
> facilitate them working together.
Fair enough
> From: Cliff Woolley [mailto:[EMAIL PROTECTED]]
>
> On Thu, 30 May 2002, Ryan Bloom wrote:
>
> > I didn't think it _had_ to auto-morph. My understanding is that the
> > default buckets do, because we assume the performance will be better
if
> > they do. That makes sense, because a file_bucket
On 30 May 2002 [EMAIL PROTECTED] wrote:
> jwoolley02/05/30 15:39:08
>
> Modified:modules/ssl ssl_engine_pphrase.c
> Log:
> This definitely gets the award for least useful error message of the month.
>
> Index: ssl_engine_pphrase.c
> ==
> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
>
> On Thu, May 30, 2002 at 05:50:45PM -0400, Cliff Woolley wrote:
> > On Thu, 30 May 2002, Justin Erenkrantz wrote:
> >
> > > The fact here is that not all buckets can be "read" such as EOS,
> > > flush, and error.
> >
> > Sure they can. They
On Thu, 30 May 2002, Ryan Bloom wrote:
> I didn't think it _had_ to auto-morph. My understanding is that the
> default buckets do, because we assume the performance will be better if
> they do. That makes sense, because a file_bucket is likely to be read
> multiple times, so it makes sense to m
> > Every bucket can be read. That is a mandatory function that all
buckets
> > must implement. If the back-end bucket-type isn't know, the filter
can
> > ALWAYS do a read/apr_bucket_make_heap.
>
> True. Though we've specified the additional semantics that
> apr_bucket_read() causes the bucket
On Thu, May 30, 2002 at 05:50:45PM -0400, Cliff Woolley wrote:
> On Thu, 30 May 2002, Justin Erenkrantz wrote:
>
> > The fact here is that not all buckets can be "read" such as EOS,
> > flush, and error.
>
> Sure they can. They just contain zero data bytes.
Right, but the problem is how are th
On Thu, 30 May 2002, Ryan Bloom wrote:
> > True, but I thought part of the idea behind buckets is so that the
> > backing type doesn't have to be known.
>
> Exactly!
Exactly. All you really need to test here is length. If the bucket is
zero bytes, that's all you need to know. That gets you al
On Thu, 30 May 2002, Justin Erenkrantz wrote:
> The fact here is that not all buckets can be "read" such as EOS,
> flush, and error.
Sure they can. They just contain zero data bytes.
> Perhaps these buckets should return an error
> if they are read? Then, if a filter sees APR_ENOTIMPL, it can
> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
>
> On Thu, May 30, 2002 at 02:43:05PM -0700, Ryan Bloom wrote:
> > This doesn't fix the underlying problem. Mod_bucketeer needs to be
> > smart enough to copy buckets if it doesn't recognize their type. If
the
> > bucket can't be copied, the
On Thu, May 30, 2002 at 02:43:05PM -0700, Ryan Bloom wrote:
> This doesn't fix the underlying problem. Mod_bucketeer needs to be
> smart enough to copy buckets if it doesn't recognize their type. If the
> bucket can't be copied, then the filter should remove the bucket from
> one brigade and add
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
> jerenkrantz02/05/30 14:10:19
>
> Modified:modules/test mod_bucketeer.c
> Log:
> mod_bucketeer needs to preserve error buckets if it sees them rather
> than silently discarding them.
This doesn't fix the underlying problem.
Hi,
just reposting this patch.
Cheers,
-Thom
--
Thom May -> [EMAIL PROTECTED]
hum, I wonder if the cargo bar is looking for staff?
gman: cargo bar sydney has an insane staff turn over rate :)
yeah, for turning over in the morning and seeing what you've woken up with.
jdub woke up with Gman
On Thu, May 30, 2002 at 01:33:45PM -0700, Justin Erenkrantz wrote:
> On Thu, May 30, 2002 at 11:02:09AM -0400, Jeff Trawick wrote:
> > Running HEAD, we get a segfault when the bogus request is for a
> > resource for which we aren't authorized. Here is the traceback:
>
> Oh, that's not good. Som
On Thu, May 30, 2002 at 11:02:09AM -0400, Jeff Trawick wrote:
> Running HEAD, we get a segfault when the bogus request is for a
> resource for which we aren't authorized. Here is the traceback:
Oh, that's not good. Something broke after I initially fixed it.
I'm trying to chase down what happen
On Thu, May 30, 2002 at 08:20:30PM -, [EMAIL PROTECTED] wrote:
> + 2) edit the path to LIBTOOL in config_vars.mk to reflect the
> + place where it was actually installed
In this case, I think it would be best if it used apr-config's
--apr-libtool option.
% /pkg/httpd-2.0/bin
On Thu, 30 May 2002, William A. Rowe, Jr. wrote:
> Perhaps we could resurrect the porting history [although I believe it's
> horribly
> incomplete] as modules/ssl/HISTORY? OTOH, those parts that are correct
> aught to have been committed to CHANGES if they were not in the first place.
they are
At 12:02 PM 5/30/2002, you wrote:
>i see value the old modules/ssl/README. it has been very handy in the
>past, and i would expect it to be for anybody coming from mod_ssl 1.3
>based sources to contribute to 2.0 or even just being brand new to the 2.0
>source. now they have lost the source roadm
On Thu, 30 May 2002, Eli Marmor wrote:
> A small wish "from the field":
>
> Will Justin's stuff be included with the RC3 of 2.0.37?
I'm still procrastinating on tagging RC2. Most of Justin's stuff is
already in, but I'm considering backing it out and waiting until RC3 since
some questions have
i see value the old modules/ssl/README. it has been very handy in the
past, and i would expect it to be for anybody coming from mod_ssl 1.3
based sources to contribute to 2.0 or even just being brand new to the 2.0
source. now they have lost the source roadmap, summary of major changes,
inco
On Thu, May 30, 2002 at 12:54:39PM -0400, Bill Stoddard wrote:
> The above section of code looks like a potential endless loop if the brigade does not
> contain an EOS bucket. Should the check for child_stopped_reading occur after the
> apr_bucket_read below?
An EOS should be returned at some poi
> jerenkrantz02/05/29 22:42:46
>
> Modified:modules/generators mod_cgid.c
> Log:
> Apply same patch to mod_cgid that was applied to mod_cgi so that it
> bypasses the *_client_block calls in favor of using the input filters
> and brigades directly.
>
> Revision ChangesPath
> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
> Sent: 30 May 2002 18:38
> On Thu, May 30, 2002 at 10:43:54AM -0500, William A. Rowe, Jr. wrote:
> > Then I'll ask a simple question before I resurrect ... Do we want individual
> > READMEs or LAYOUTs that describe all the files throughout eac
On Thu, May 30, 2002 at 10:43:54AM -0500, William A. Rowe, Jr. wrote:
> Then I'll ask a simple question before I resurrect ... Do we want individual
> READMEs or LAYOUTs that describe all the files throughout each Apache
> source tree directory, only one top-level LAYOUT that describes the entire
Which module would be a good example for someone who wants to rewrite an
existing
ap_*_client_block
based module?
Tks
Brian Pane wrote:
>On Thu, 2002-05-30 at 01:23, Justin Erenkrantz wrote:
>
>
>
>>- As a side effect, a lot of 8k static buffer allocations have
>> been removed. (I can he
At 01:07 AM 5/30/2002, you wrote:
>On Thu, 30 May 2002, William A. Rowe, Jr. wrote:
>
> > is modules/ssl/README even valuable anymore?
>
>yes. fine to remove the stale stuff, but not the whole damn thing. there
>was a useful roadmap of the source in there ...
Then I'll ask a simple question bef
On Thu, 2002-05-30 at 01:23, Justin Erenkrantz wrote:
> - As a side effect, a lot of 8k static buffer allocations have
> been removed. (I can hear the Netware guys cheering from here.)
> - This should also greatly reduce the number of copies that the
> input data should have to go through as
On Thu, May 30, 2002 at 03:00:21PM +0530, Vinod Panicker wrote:
> I feel like kicking myself! Forgot all that I had learnt abt sockets!
>
> What I actually wanted was the ability to use the socket from another
> process. I obviously cant do that in this case since the socket that
> has been ope
Jeff Trawick <[EMAIL PROTECTED]> writes:
> Jeff Trawick <[EMAIL PROTECTED]> writes:
>
> > okay, do try it, but (unlike somebody last night) don't try it on daedalus
> >
> > GET / HTTP/1.1
> > Accept: */*
> > Host: test
> > Content-Type: application/x-www-form-urlencoded
> > Transfer-Encoding: c
A small wish "from the field":
Will Justin's stuff be included with the RC3 of 2.0.37?
--
Eli Marmor
[EMAIL PROTECTED]
CTO, Founder
Netmask (El-Mar) Internet Technologies Ltd.
__
Tel.: +972-9-766-1020 8 Yad-Harutzim St.
Fax.:
Justin Erenkrantz wrote:
>
> On Thu, May 30, 2002 at 07:34:00AM -, [EMAIL PROTECTED] wrote:
> > jerenkrantz02/05/30 00:34:00
> >
> > Modified:.CHANGES
> >modules/proxy mod_proxy.c proxy_http.c
> > Log:
> > Switch mod_proxy to using the brigade/filter call
I'm running Apache 2.0.36-dev on Win2K, with SSL enabled. Most clients
are Win2K systems using either Netscape 6.x, IE5.5 or Mozilla RC1, and
they connect and browse without problems.
One client is a Mac OS X using IE5.0. It is constantly receiving 'Data
Encryption Errors'. On pages where t
Jeff Trawick <[EMAIL PROTECTED]> writes:
> okay, do try it, but (unlike somebody last night) don't try it on daedalus
>
> GET / HTTP/1.1
> Accept: */*
> Host: test
> Content-Type: application/x-www-form-urlencoded
> Transfer-Encoding: chunked
>
> AAA
Is this test (with cr-lf ad
Martin Kraemer wrote:
> About the X-Forwarded-* stuff: It's non-standard anyway (you can add
> any X-whatever header and still be RFC2616 compliant) so I'd rather
> not see it in 1.3 now (maybe in the next release ;-)
>
> I've seen proxies like squid hang because of nonstandard headers
> (proxy-
On Thu, May 30, 2002 at 05:57:33AM -, [EMAIL PROTECTED] wrote:
> jwoolley02/05/29 22:57:33
>
> Modified:include ap_mmn.h
> Log:
> Imagine the horror. I go to try compiling PHP4, and it bombs out on
> r->boundary. BUT WAIT, I say, we have a test in there for that:
> #if !M
* Sander Striker ([EMAIL PROTECTED]) wrote :
> > From: Cliff Woolley [mailto:[EMAIL PROTECTED]]
> > Sent: 30 May 2002 02:41
>
> [...]
> > > Log:
> > > Catch up with the apr_allocator_set_owner -> apr_allocator_owner_set renames
> > > in APR.
> >
> > This requires an MMN bump (which is fine
I feel like kicking myself! Forgot all that I had learnt abt sockets!
What I actually wanted was the ability to use the socket from another
process. I obviously cant do that in this case since the socket that
has been opened is local to the process (DUH!)
Now I want to pass this socket to anot
> From: Tony Finch [mailto:[EMAIL PROTECTED]]On Behalf Of 'Tony
> Finch'
> Sent: 30 May 2002 11:01
> On Thu, May 30, 2002 at 11:03:05AM +0530, Vinod Panicker wrote:
> >
> > I need the actual socket that apache uses to communicate with the client
> > in the php module. Is it available somewhere
On Thu, May 30, 2002 at 11:03:05AM +0530, Vinod Panicker wrote:
>
> I need the actual socket that apache uses to communicate with the client
> in the php module. Is it available somewhere in the request_rec
> structure?
You've already found it in r->connection->client->fd.
Tony.
--
f.a.n.finc
On Thu, May 30, 2002 at 07:34:00AM -, [EMAIL PROTECTED] wrote:
> jerenkrantz02/05/30 00:34:00
>
> Modified:.CHANGES
>modules/proxy mod_proxy.c proxy_http.c
> Log:
> Switch mod_proxy to using the brigade/filter calls directly rather than
> the *_client_b
58 matches
Mail list logo
