On 27-Jun-07, at 1:01 PM, Joshua Slive wrote:
On 6/27/07, Nick Kew [EMAIL PROTECTED] wrote:
This is a problem that could be solved by documentation.
Maybe not quite as simple, but when the alternative is accepting
new connections whilst running as root.
Here's a start:
On 27-Jun-07, at 6:07 PM, Joshua Slive wrote:
Good point. I moved some of this discussion into its own section,
since it applies equally to the main example.
Yes, that's much better.
I also removed your comments about needing separate LockFile/etc
locations, since its not true in recent
Brian McCallister wrote:
I am leaning towards changing all the userdata types (request_rec,
server_rec, conn_rec, apr_table_t) in mod_wombat to have anonymous
metatables rather than the current setup where they share a metatable.
+1
The drawback is that we lose the ~type safety of being
A few comments intermingled into the patch:
Brian McCallister wrote:
On Apr 30, 2007, at 2:02 PM, Akins, Brian wrote:
--- apr_lua.c (revision 0)
+++ apr_lua.c (revision 0)
@@ -0,0 +1,55 @@
+#include apr.h
+#include apr_tables.h
+
+#include lua.h
+#include lauxlib.h
+#include lualib.h
+
On 3-Aug-05, at 8:11 AM, William A. Rowe, Jr. wrote:
In the APR library, yes, we translate 'apr_sendfile' to TransmitFile()
on win32. Some other magic occurs to obtain a file handle which can
be passed to TransmitFile. But there are enough flaws in the TF() api
that perhaps this would be
On 27-Jun-05, at 4:47 AM, luca regini wrote:
I see that the symbols ap_conftree and ap_top_module are not defined
in any header but only in the source code. Mod_info uses this symbols.
I need to do something similar to what mod_info does but in a shared
module. Is there a way to do it?? The
On 20-Jun-05, at 8:55 AM, jean-frederic clere wrote:
and GET with content-length.
I think that is not forbidden in the rfc...
But what about returning HTTP_BAD_REQUEST if Content-Length is not 0?
I don't believe rfc2616 forbids GET requests to have entity-bodies, so
it could be argued that
On 27-May-05, at 10:53 AM, Jess Holle wrote:
Russell Howe wrote:Jess Holle wrote:
Is there any remaining/ongoing interest in this development area?
The need to authenticate a single resource against multiple disparate
(non-failover/non-redundant) LDAP servers looms large and I'd like to
On 1-May-05, at 7:04 PM, Jeff Trawick wrote:
I found a description of the problem:
When Apache issues a redirect in response to a client request, the
response
includes some actual text to be displayed in case the client can't
(or doesn't)
automatically follow the redirection. Apache ordinarily
On 26-Apr-05, at 5:28 AM, Joe Orton wrote:
This is really just a should we provide extra API guarantees to
prevent
users shooting themselves in the foot debate, right? Let's agree to
disagree :)
Fair enough. I guess where I'm coming from is that I'm a user of the
API, and my feet have been shot
The docstring in util_filter.h for ap_get_brigade says:
* Get the current bucket brigade from the next filter on the filter
* stack. The filter returns an apr_status_t value. If the bottom-most
* filter doesn't read from the network, then ::AP_NOBODY_READ is
returned.
* The bucket brigade
On 26-Apr-05, at 6:58 PM, Brad Nicholes wrote:
I just checked in a patch to move the ldap_set_option() call from
trying to set the connection timeout globally to ldap connection
specific. I don't have a good way to test that it fixes the problem,
but if somebody can verify the fix, I will
On 25-Apr-05, at 10:15 AM, Cliff Woolley wrote:
4. switch to allocate brigades out of the bucket allocator
Didn't we try #4 before and something bad happened? I don't remember
what that would have been, I just feel certain #4 has been previously
discussed at least.
I think the something bad would
On 25-Apr-05, at 8:29 AM, Joe Orton wrote:
I think it's fine to leave the *contents* of the brigade as undefined
after a call to ap_pass_brigade. (that's essentially the case now
since
it's not explicitly defined to be empty: I don't know of any
particular bugs which have been caused by this?)
On 25-Apr-05, at 12:05 PM, Joe Orton wrote:
Fragile, why? That's exactly the right approach as far as I can see.
Because the pool might have a lifetime *longer than* the bucket
allocator. OK, that's not likely in the current architecture, so it
would be a concern only for non-httpd
Regardless of any other changes to the brigade API, this seems to me to
be a good idea:
Index: util_filter.c
===
--- util_filter.c (revision 158730)
+++ util_filter.c (working copy)
@@ -500,6 +500,7 @@
Patch to use a single temporary brigade instead of creating a new one
on each invocation:
(also does a little code reuse)
Index: mod_ext_filter.c
===
--- mod_ext_filter.c(revision 158730)
+++ mod_ext_filter.c(working copy)
I didn't reindent so that the patch would be clearer.
Index: mod_include.c
===
--- mod_include.c (revision 158730)
+++ mod_include.c (working copy)
@@ -3542,7 +3542,6 @@
intern-end_seq_len =
On 25-Apr-05, at 1:30 PM, Justin Erenkrantz wrote:
--On Monday, April 25, 2005 12:47 PM -0500 Rici Lake
[EMAIL PROTECTED] wrote:
Regardless of any other changes to the brigade API, this seems to me
to
be a good idea:
Index: util_filter.c
On 25-Apr-05, at 3:36 PM, Justin Erenkrantz wrote:
--On Monday, April 25, 2005 3:06 PM -0500 Rici Lake
[EMAIL PROTECTED] wrote:
Can you quantify that large overhead? In the case of a 'compliant'
filter, it consists of:
With Joe's suggestion for 'creator must destroy', this step is wholly
Index: mod_include.c
===
--- mod_include.c (revision 158730)
+++ mod_include.c (working copy)
@@ -3060,7 +3060,7 @@
struct ssi_internal_ctx *intern = ctx-intern;
request_rec *r = f-r;
apr_bucket *b =
Why do pool buckets do an automatic setaside? Should they?
No other bucket type does this; consequently, if you want to hold on to
a bucket beyond the scope of the call in which you received the
brigade, you must explicitly call bucket_setaside.
Without examining the bucket type, a practice
On 25-Apr-05, at 4:27 PM, André Malo wrote:
* Rici Lake wrote:
+1 in general, but ...
...put it into the internal structure, please. That's I've created it
for
(binary compat and only making stuff public what matters the public).
nd
--
Muschelflucht-Zusatzeinrichtung.
Shell-Escape ist ja noch
On 25-Apr-05, at 5:04 PM, Cliff Woolley wrote:
Why do pool buckets do an automatic setaside? Should they?
They set themselves aside when the pool in which their data was
allocated
is in the process of being destroyed. This is necessary because no
other
bucket type has a similarly unpredictable
On 25-Apr-05, at 4:26 PM, Joe Orton wrote:
On Mon, Apr 25, 2005 at 03:58:59PM -0500, Rici Lake wrote:
If we accept that the contents of a brigade are undefined when
ap_pass_brigade returns, the caller has three options:
-- call cleanup and reuse the brigade
-- call destroy (which will first call
On 22-Apr-05, at 6:19 AM, Nick Kew wrote:
However, I think it is a fallacy that a cleaned-up brigade is not too
big to wait for pool cleanup. The brigade itself is about four
pointers;
and the corresponding pool cleanup is another four pointers, so
that's a
total of around 32 bytes, not a
On 22-Apr-05, at 9:32 AM, Joe Orton wrote:
The issue here is really which party can *destroy* a brigade, right?
Or perhaps which party *must* destroy a brigade. This is much less of
an issue if neither party creates a new brigade on every filter
invocation. But some do.
In the current code
After a filter calls ap_pass_brigade(f-next, bb), who owns bb?
The name of the function might lead one to believe that ownership of
the brigade was transferred, but inspection of distributed filters
shows that it has not been; both mod_deflate and mod_include expect the
brigade to be usable
On 21-Apr-05, at 3:58 PM, Cliff Woolley wrote:
FWIW, the documentation says:
The caller relinquishes ownership of the brigade.
This obviously differs from what some of our own filters are doing --
and
from my memory of past history. It makes sense that it should be this
way, though I think at
On 21-Apr-05, at 5:51 PM, Nick Kew wrote:
Rici Lake wrote:
FWIW, I think the (apparent) practice, where the caller relinquishes
ownership of the buckets but not the brigade itself, is more efficient
since it avoids a lot of brigade construction and destruction.
Agreed. And it works for any
On 18-Apr-05, at 9:43 AM, Greg Ames wrote:
if the network data for pipelined request n+1 isn't already present
during ap_read_request for request n, it is highly unlikely to arrive
by the time we start writing the response for request n.
It may well arrive during the time we're writing the
On 17-Apr-05, at 5:30 PM, Roy T. Fielding wrote:
On Apr 17, 2005, at 1:25 PM, [EMAIL PROTECTED] wrote:
+
+ *) mod_deflate: Merge the Vary header, isntead of Setting it. Fixes
+ applications that send the Vary Header themselves, and also
apply
+ mod_defalte as an output filter. [Paul
This didn't quite get it right, either. It will overwrite the .conf
file unless the .conf file is httpd.conf (rather than progname.conf)
--- Makefile.in Sun Apr 17 20:51:18 2005
+++ Makefile.in.new Sun Apr 17 20:51:50 2005
@@ -78,7 +78,7 @@
if [ $$i = httpd.conf ]; then \
On 15-Apr-05, at 11:06 AM, Justin Erenkrantz wrote:
The problem with this code is that it'll only read 8 characters worth
of
CRLFs. We'd probably want to retry the reads until we don't get more
CRLF
pairs. It's not determinate how many extra CRLFs we will get.
Are there browsers which send
On 15-Apr-05, at 10:56 AM, Greg Ames wrote:
the reason that this and the corresponding 1.3 BUFF logic exists is to
minimize tinygrams - ip packets that are less than a full mtu size.
tinygrams definately degrade network performance and trigger things
like Nagle's algorithm. in this particular
I was taking a look at the implementation of the renamed (but still
misleading) AP_MODE_EATCRLF, in an attempt to figure out what a
conforming input filter ought to do if it's handed that mode.
Some comments:
1) The loop in server/core_filters.c:226
while (c str + len) {
Just a query: I was looking at the code for mod_proxy.c and I wonder if
the behaviour is really correct.
At line 632, it loops through the configured proxy hosts, trying
proxy_run_scheme_handler on each one. If it receives any return code
other than DECLINED or HTTP_BAD_GATEWAY, it accepts the
This is a small patch to mod_proxy which implements a single directive:
ProxyAuthOverride 403|404|Off
It overrides 401 returns from the origin server and substitutes them
with the indicated status code.
This may be an unusual use case, but it does come up once in a while
when trying to proxy
On 8-Apr-05, at 1:40 PM, Graham Leggett wrote:
In theory (if I understand it correctly) it wouldn't - because it
would only try the direct connection on DECLINED or bad gateway - if
authentication was denied, the result would be neither DECLINED nor
bad gateway, and so the direct connection
On 6-Apr-05, at 11:43 AM, Phil Lello wrote:
As part of this, it could be useful to generate a RunningConfig.cnf
file as part httpd startup, which would be a merged config file with
comments indicating which file set the option (and possibly which
options have taken defaults).
You can get easily
On 6-Apr-05, at 12:56 PM, Mads Toftum wrote:
mod_asis: yes - no
I'd prefer - most as it is rarely used but not totally useless.
Others mentioned mod_ssl which I think is too much trouble to be worth
enabling other than when requested explicitly - there's the whole
crypto
regs issue and it does
On 31-Mar-05, at 6:16 AM, Nick wrote:
As a refinement;
The timer firstly sends a signal to the CGI program which may be
caught by the CGI program to generate some form of output. This output
will prove whether the http connection is still open. If the CGI
program doesn't output anything, a TERM
On 30-Mar-05, at 12:52 PM, Sander Striker wrote:
#EnableSendfile off
I'd suggest uncommenting that for a win32 config file.
On 22-Mar-05, at 5:17 PM, Graham Leggett wrote:
This is also broken - the LDAPTrustedClientCert is supposed to have
scope on a per directory basis.
To fix this, we would need to add a directory config creator, and a
directory config merger, is that correct?
Sure, but then there is still a
While I've got util_ldap.c open in front of me, I also noticed that the
following code occurs a number of times:
/*
* If any LDAP operation fails due to LDAP_SERVER_DOWN, control
returns here.
*/
start_over:
if (failures++ 10) {
return result;
}
if
The referenced commit added two OR_ALL directives to util_ldap:
LDAPTrustedClientCert
LDAPTrustedMode
However, that module has no per-directory config struct; all
configuration is stored in per-server structs.
Consequently, as far as I can see, the OR_ALL directives are
unworkable. In
Bill,
What's the performance problem?
There was someone on #apache yesterday who claimed to experience the
following problem: On a local switched network, Apache2 on Win2K3
transferred at 800kbps, while IIS on the same box transferred at
8-11mbps. When he replaced the cable to the server with a
OK, the person came back, I got him to disable sendfile, and apache
started transferring at full speed.
I believe sendfile should be disabled by default at least on Windows.
Rici
On 17-Mar-05, at 11:48 AM, Rici Lake wrote:
Bill,
What's the performance problem?
There was someone on #apache
The ProxyRemoteMatch directive is supposed to use a regex to redirect
certain proxy requests to a remote proxy server (as I understand the
documentation). I actually needed that for a configuration (see below)
and was puzzled to find that it doesn't work: (line numbers from
APACHE_2_0_BRANCH,
With reference to [Re: svn commit: r111596]
The following proposal attempts to provide a simple way of configuring
a server which supports multiple protocols (http, ftp, nntp) while
allowing the administrator and/or packager to configure OS kernel-
implemented accept filters, as provided by
(An addendum to the previous mod_acceptfilter proposal.)
From my experience on #apache, it appears that Mere Mortals have
a great deal of difficulty successfully configuring virtual hosts.
I think this is understandable; the algorithm used to allocate
requests to virtual host sections is
On 29-Nov-04, at 11:02 AM, William A. Rowe, Jr. wrote:
Yes, but our API dictates that they are looking for ...
(in the case of this module) - which is a bad thing IMHO (and in
Greg's and Ryan's as well)...
Sorry, I don't understand that. The search for is in the first line
of the directive; arg
On 29-Nov-04, at 4:05 AM, André Malo wrote:
* Paul Querna wrote:
What is wrong with IfDefine 0?
It's ugly and non-intuitive.
Just out of curiousity, what do people think is wrong with the
Comment directive implemented by this micro-module:
On 29-Nov-04, at 10:10 AM, Greg Stein wrote:
So no... I don't like mod_comment. It uses a feature that I dearly
wish to see removed from httpd.
I agree 100% on removing that feature. If it were gone, something
like mod_comment would have to be implemented in the core, I suppose.
However, I was not
Rephrasing the question slightly:
On 29-Nov-04, at 9:44 AM, Rici Lake wrote:
Just out of curiousity, what do people think is wrong with the
Comment directive implemented by this micro-module:
I meant to ask: What do people think about a Comment
directive, which would simply absorb
On 25-Oct-04, at 3:37 AM, Graham Leggett wrote:
+else if (r-connection-keepalive !=
AP_CONN_KEEPALIVE) {
+ap_log_rerror(APLOG_MARK, APLOG_NOTICE, rv, r,
+ request line read error.);
+}
Is it possible to put a more
On 25-Oct-04, at 11:04 PM, Roy T. Fielding wrote:
This is not an error that the server admin can solve -- it is normal
life on the Internet. We really shouldn't be logging it except when
on DEBUG level.
That was my first reaction, too. However, Ivan Ristic pointed out that
(in some cases, anyway)
With all due respect, I don't think the following scenario
will be logged by the patch; it only reports when the attempt
to read the initial request line fails, not when the socket
is closed prior to data transfer terminating. At least, that
was the intent.
I'll leave it to Ivan to try and make
On 18-Oct-04, at 9:03 PM, Bennett, Tony - CNF wrote:
It only builds the module specified in the last --with-module
directive.
Is this a limitation with that directive ???
Yes, the directive only handles one module.
Lines 250-263 of server/protocol.c:
250/* Would this overrun our buffer? If so, we'll die. */
251if (n bytes_handled + len) {
252*read = bytes_handled;
253if (*s) {
254/* ensure this string is terminated */
255if
On 21-Sep-04, at 11:03 AM, Joe Orton wrote:
pass 2: bytes_handled = 8191, *s = 8191-byte region
Quite right: I hadn't looked closely enough at the case where there was
no user-supplied buffer :(
Ok, bytes_handled can never be n, right?
So the following ought to work:
255if
I want to make it clear here that I have never used Reiser4, so on a
personal level the issue is somewhat academic.
On 9-Sep-04, at 1:11 AM, André Malo wrote:
SUSv3/POSIX disagrees as well. So I think, Mr. Reiser should just fix,
what's broken. It's not such an uncommon case to test an arbitrary
On 9-Sep-04, at 12:48 PM, William A. Rowe, Jr. wrote:
You miss a case with this patch...
Consider a request for /content/foo/index.php/extra-path-info
The path doesn't end where you think it does, and directory walk
would usually handle this case. Perhaps a patch to perform an
extra sanity check
On 6-Sep-04, at 10:37 AM, Ivan Ristic wrote:
[ The request is trivial to implement (at least I think so),
but the feature itself is very important. ]
Perhaps I don't understand the request, but wouldn't it be
straightforward for a module like mod_security to implement
this feature by using one
I put the gory details on Bugzilla
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=31126); I honestly
don't know what the best way to fix this problem is, though.
Basically, ap_directory_walk will, under certain circumstances, attempt
to read an .htaccess file from a complete filepath; that
Is it metadata about the body? In many cases, a cookie is
semantically information about the session; it might have
nothing to do with the particular body at all.
On 29-Aug-04, at 5:57 PM, Jim Jagielski wrote:
I myself would define the cookie header as an entity header,
since it *is* meta data
Bug report with patch file attached:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30919
mod_info seems to get all confused in cases like this:
Location /x
Order deny,allow
Allow from all
AuthType Basic
AuthName Foo
AuthUserFile .htpasswd
LimitExcept PUT
On 1-Aug-04, at 4:41 PM, Justin Erenkrantz wrote:
Instead, what mod_proxy could do is expose a user directive that says
'no representation transformation allowed' and act accordingly: bypass
all filters except for the network filters.
In fact, if the filter chain cannot optimise byte ranges,
On 20-Jul-04, at 3:33 PM, Tsuyoshi SASAMOTO wrote:
Please refer to this discussion about thread safety of setjmp/longjmp:
http://groups.google.com/groups?
[EMAIL PROTECTED]
The signal-to-noise ratio in that thread is very low :)
It is clear that setjmp/longjmp are *not* signal-safe;
:
At 10:18 PM 6/8/2004, Rici Lake wrote:
The patch is now posted to bugzilla as [Bug 29450]. I believe that
conforms to the patches.html document cited below. Although that
document says -C3 is acceptable, I have submitted it in the
preferential -u format (which I also prefer, actually).
It says use
Quoting Joshua Slive [EMAIL PROTECTED]:
On Sat, 5 Jun 2004, Jeff Trawick wrote:
What about enabling via a per-dir directive? Looks very useful, but some
sites
might have a significant number of new entries in error log serving no
useful
purpose (for them).
The problem with per-dir
71 matches
Mail list logo
