Re: mod_python 3.2.3b available for testing
Nick wrote: More info: python 2.4.2 on Linux: import tempfile t = tempfile.TemporaryFile() t open file 'fdopen', mode 'w+b' at 0xb7df07b8 type(t) type 'file' dir(t) ['__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', '__init__', '__iter__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', 'close', 'closed', 'encoding', 'fileno', 'flush', 'isatty', 'mode', 'name', 'newlines', 'next', 'read', 'readinto', 'readline', 'readlines', 'seek', 'softspace', 'tell', 'truncate', 'write', 'writelines', 'xreadlines'] python 2.4.1 on windows: import tempfile t = tempfile.TemporaryFile() t open file 'fdopen', mode 'w+b' at 0x0099FBA8 type(t) type 'instance' dir(t) ['__doc__', '__getattr__', '__init__', '__module__', '__repr__', 'close_called', 'file', 'name'] So this is an inconsistency within Python. Should mod_python attempt to correct it, or just claim a Python bug? I think we should correct it. I'm sure users don't care that we implement this with TemporaryFile. That being said, I wonder how many applications on Windows we may break by fixing this? Version 3.1.4 also used TemporaryFile, so this is not a new bug. Jim Nick wrote: This may be a Python Windows thing, but it shows up in mod_python: When using util.FieldStorage on multipart/form-data encoded POST data containing a file, in Linux a field.file will yield a file object (actually a subclass of file), but in Windows you have to get the file object through field.file.file. This probably has something to do with the fact that Windows' implementation of tempfile.TemporaryFile is different from Linux, but it should be made consistent in the mod_python interface. Nick
Re: mod_python 3.2.3b available for testing
Jim Gallacher wrote: So this is an inconsistency within Python. Should mod_python attempt to correct it, or just claim a Python bug? I think we should correct it. I'm sure users don't care that we implement this with TemporaryFile. That being said, I wonder how many applications on Windows we may break by fixing this? Version 3.1.4 also used TemporaryFile, so this is not a new bug. Yeah, I never noticed it either until someone pointed it out to me. I appreciated the change to TemporaryFile, but being primarily a Linux user I never noticed that this broke my code in Windows. In any case, I'm still gonna have to implement a workaround in my own code to catch people using the different versions of mod_python out there, so I can live with whatever decision you guys make. But here's +1 for making the interface consistent at least for mod_python users. As for code breakage, I would consider this a bug introduced in 3.1.4, which was the last official release of mod_python, which will be corrected in release 3.3. Nick
Re: mod_python 3.2.3b available for testing
Jim Gallacher wrote:
Nick wrote:
More info:
python 2.4.2 on Linux:
import tempfile
t = tempfile.TemporaryFile()
t
open file 'fdopen', mode 'w+b' at 0xb7df07b8
type(t)
type 'file'
dir(t)
['__class__', '__delattr__', '__doc__', '__getattribute__',
'__hash__', '__init__', '__iter__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__str__', 'close',
'closed', 'encoding', 'fileno', 'flush', 'isatty', 'mode', 'name',
'newlines', 'next', 'read', 'readinto', 'readline', 'readlines',
'seek', 'softspace', 'tell', 'truncate', 'write', 'writelines',
'xreadlines']
python 2.4.1 on windows:
import tempfile
t = tempfile.TemporaryFile()
t
open file 'fdopen', mode 'w+b' at 0x0099FBA8
type(t)
type 'instance'
dir(t)
['__doc__', '__getattr__', '__init__', '__module__', '__repr__',
'close_called', 'file', 'name']
So this is an inconsistency within Python. Should mod_python attempt
to correct it, or just claim a Python bug?
I think we should correct it. I'm sure users don't care that we
implement this with TemporaryFile. That being said, I wonder how many
applications on Windows we may break by fixing this? Version 3.1.4 also
used TemporaryFile, so this is not a new bug.
Are you sure there is anything to correct? In both cases, the object has
the same methods available for manipulating files (t.write('a'), for
example). They are not the same type of object, so they have different
dir() output, but don't they have the same functionality? What
specifically gets broken in util.FieldStorage?
Re: mod_python 3.2.3b available for testing
Nick wrote: Jim Gallacher wrote: So this is an inconsistency within Python. Should mod_python attempt to correct it, or just claim a Python bug? I think we should correct it. I'm sure users don't care that we implement this with TemporaryFile. That being said, I wonder how many applications on Windows we may break by fixing this? Version 3.1.4 also used TemporaryFile, so this is not a new bug. Yeah, I never noticed it either until someone pointed it out to me. I appreciated the change to TemporaryFile, but being primarily a Linux user I never noticed that this broke my code in Windows. In any case, I'm still gonna have to implement a workaround in my own code to catch people using the different versions of mod_python out there, so I can live with whatever decision you guys make. But here's +1 for making the interface consistent at least for mod_python users. As for code breakage, I would consider this a bug introduced in 3.1.4, which was the last official release of mod_python, which will be corrected in release 3.3. You may have misunderstood. I was not suggesting that tempfile.TemporaryFile was introduced in 3.1.4, only that it existed there. Looking at the svn repository I see it's used in 3.0.0-beta and 2.7.9, so this bug has been lurking for a while. ;) Regards, Jim
Re: mod_python 3.2.3b available for testing
Jim Gallacher wrote: You may have misunderstood. I was not suggesting that tempfile.TemporaryFile was introduced in 3.1.4, only that it existed there. Looking at the svn repository I see it's used in 3.0.0-beta and 2.7.9, so this bug has been lurking for a while. ;) Yes, although the fact that the implementation of TemporaryFile changed in Python 2.3 may have something to do with it. I honestly don't remember what the previous behavior was, but it worked OK for me at one time :) Nick
Re: mod_python 3.2.3b available for testing
Indrek Järve wrote: This behaviour has been with Python for quite a while, so claiming it's simply a Python bug will be the same as declaring we don't support Windows. Our company's software that runs on Windows and uses mod_python simply patches util.py with the following change: 227c227 if isinstance(item.file, FileType): --- if isinstance(item.file, FileType) or (hasattr(item.file, 'file') and isinstance(item.file.file, FileType)): I haven't tried this with mp32 yet (we're still running on Python 2.3 and I haven't had time to investigate how to compile mp on Windows), but on 3.0/3.1 it appears to work just fine for our customers. The relevant part of FieldStorage has changed in 3.2. isinstance(item.file, FileType) or \ isinstance(getattr(item.file, 'file', None), FileType): so no more patching for you! Now I just need to understand what Nick is on about. ;) Jim Nick wrote: More info: python 2.4.2 on Linux: import tempfile t = tempfile.TemporaryFile() t open file 'fdopen', mode 'w+b' at 0xb7df07b8 type(t) type 'file' dir(t) ['__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', '__init__', '__iter__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', 'close', 'closed', 'encoding', 'fileno', 'flush', 'isatty', 'mode', 'name', 'newlines', 'next', 'read', 'readinto', 'readline', 'readlines', 'seek', 'softspace', 'tell', 'truncate', 'write', 'writelines', 'xreadlines'] python 2.4.1 on windows: import tempfile t = tempfile.TemporaryFile() t open file 'fdopen', mode 'w+b' at 0x0099FBA8 type(t) type 'instance' dir(t) ['__doc__', '__getattr__', '__init__', '__module__', '__repr__', 'close_called', 'file', 'name'] So this is an inconsistency within Python. Should mod_python attempt to correct it, or just claim a Python bug? Nick Nick wrote: This may be a Python Windows thing, but it shows up in mod_python: When using util.FieldStorage on multipart/form-data encoded POST data containing a file, in Linux a field.file will yield a file object (actually a subclass of file), but in Windows you have to get the file object through field.file.file. This probably has something to do with the fact that Windows' implementation of tempfile.TemporaryFile is different from Linux, but it should be made consistent in the mod_python interface. Nick
Re: mod_python 3.2.3b available for testing
Jorey Bump wrote:
Jim Gallacher wrote:
Nick wrote:
More info:
python 2.4.2 on Linux:
import tempfile
t = tempfile.TemporaryFile()
t
open file 'fdopen', mode 'w+b' at 0xb7df07b8
type(t)
type 'file'
dir(t)
['__class__', '__delattr__', '__doc__', '__getattribute__',
'__hash__', '__init__', '__iter__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__str__', 'close',
'closed', 'encoding', 'fileno', 'flush', 'isatty', 'mode', 'name',
'newlines', 'next', 'read', 'readinto', 'readline', 'readlines',
'seek', 'softspace', 'tell', 'truncate', 'write', 'writelines',
'xreadlines']
python 2.4.1 on windows:
import tempfile
t = tempfile.TemporaryFile()
t
open file 'fdopen', mode 'w+b' at 0x0099FBA8
type(t)
type 'instance'
dir(t)
['__doc__', '__getattr__', '__init__', '__module__', '__repr__',
'close_called', 'file', 'name']
So this is an inconsistency within Python. Should mod_python attempt
to correct it, or just claim a Python bug?
I think we should correct it. I'm sure users don't care that we
implement this with TemporaryFile. That being said, I wonder how many
applications on Windows we may break by fixing this? Version 3.1.4
also used TemporaryFile, so this is not a new bug.
Are you sure there is anything to correct? In both cases, the object has
the same methods available for manipulating files (t.write('a'), for
example). They are not the same type of object, so they have different
dir() output, but don't they have the same functionality? What
specifically gets broken in util.FieldStorage?
No, I'm not sure. Now that I play around with it I'm not sure I
understand the problem at all. Perhaps Nick could elaborate?
Testing with python3.2.3 on Wine:
import tempfile
from types import *
t = tempfile.TemporaryFile()
t
open file 'fdopen', mode 'w+b' at 0x40D6A560
t.file
open file 'fdopen', mode 'w+b' at 0x40D6A560
t.write('stuff')
t.seek(0)
t.read()
isinstance(t, FileType)
False
Other than the fact that isinstance(t, FileType): returns False, I
don't see the problem. Nick?
Jim
Static build of libapreq2-2.07-rc3
Just for kicks, I tried that today with Apache 2.1.8-beta. The instructions are a bit stale in the INSTALL script. Here are the questions to the points mentioned under static install: 1. What is the CPPFLAGS -I supposed to be? Top level libapreq2 source directory? Or some other directory under it (e.g. module/apache2)? 2. What is HTTPD_LDFLAGS supposed to be (i.e. we should tell people where to expect libapreq2.la)? An example would be great. 3. The env/mod_apreq2.c doesn't exist any more. Should we say module/apache2/filter.c or module/apache2/handler.c? Or something else? I tried a few combos, but the configure process of libapre2 tells me invalid apr-config location, where this is actually APR 1.x (as shipped with Apache 2.1.8), so it should be looking for apr-1-config anyway (which exists in srclib/apr directory of Apache 2.1.8)... I don't use this config (i.e. I use dynamic build, which work fine), but some people may. It would be good if we could document/test this before the release of 2.07. -- Bojan
Re: svn commit: r327945 - in /httpd/httpd/trunk: CHANGES modules/http/http_core.c modules/http/http_request.c server/mpm/experimental/event/event.c
On Mon, Oct 24, 2005 at 03:33:17AM -, Brian Pane wrote: Author: brianp Date: Sun Oct 23 20:33:14 2005 New Revision: 327945 URL: http://svn.apache.org/viewcvs?rev=327945view=rev Log: Async write completion for Event MPM (backported from async-dev branch to 2.3 trunk) httpd-test runs against the trunk are failing all over the place today, I guess caused by one of these changes... prefork is failing like: Failed TestStat Wstat Total Fail Failed List of Failed --- t/modules/proxy.t13 11 84.62% 1-9 12-13 t/modules/proxy_balancer.t11 100.00% 1 t/modules/rewrite.t 225 22.73% 17-18 20-22 t/protocol/echo.t 255 65280 88 100.00% 1-8 t/security/CAN-2005-2700.t21 50.00% 1 ... plus almost all of t/ssl/* fail and similarly for worker, which also triggers a segfault in the proxy (attached the log output for worker) joe + ./t/TEST [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl /tmp/regressy17180/pf-trunk-worker/t/TEST /tmp/regressy17180/trunk-worker-root/bin/httpd -d /tmp/regressy17180/pf-trunk-worker/t -f /tmp/regressy17180/pf-trunk-worker/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS using Apache/2.3.0-dev (worker MPM) waiting 180 seconds for server to start: ... waiting 180 seconds for server to start: ok (waited 2 secs) server localhost.localdomain:8529 started server localhost.localdomain:8530 listening (mod_nntp_like) server localhost.localdomain:8531 listening (mod_nntp_like_ssl) server localhost.localdomain:8532 listening (mod_ssl) server localhost.localdomain:8533 listening (ssl_optional_cc) server localhost.localdomain:8534 listening (mod_cache) server localhost.localdomain:8535 listening (proxy_http_reverse) server localhost.localdomain:8536 listening (mod_headers) server localhost.localdomain:8537 listening (mod_echo) server localhost.localdomain:8538 listening (mod_echo_ssl) server localhost.localdomain:8539 listening (error_document) server localhost.localdomain:8540 listening (mod_proxy) server localhost.localdomain:8541 listening (proxy_http_bal1) server localhost.localdomain:8542 listening (proxy_http_bal2) server localhost.localdomain:8543 listening (proxy_http_balancer) server localhost.localdomain:8544 listening (mod_vhost_alias) server localhost.localdomain:8545 listening (mod_include) server localhost.localdomain:8546 listening (proxy_http_https) server localhost.localdomain:8547 listening (proxy_https_https) server localhost.localdomain:8548 listening (proxy_https_http) [ info] adding source lib /tmp/regressy17180/pf-trunk-worker/Apache-Test/lib to @INC [ info] adding source lib /tmp/regressy17180/pf-trunk-worker/Apache-Test/lib to @INC [ info] adding source lib /tmp/regressy17180/pf-trunk-worker/Apache-Test/lib to @INC t/apache/404ok t/apache/acceptpathinfo.ok t/apache/byterange..ok t/apache/byterange2.ok t/apache/chunkinput.ok t/apache/contentlength..ok t/apache/errordoc...ok t/apache/etags..ok t/apache/getfileok t/apache/headersok t/apache/limits.ok t/apache/optionsok t/apache/passbrigadeok t/apache/post...ok t/apache/pr35292ok t/apache/pr35330ok t/apache/rwrite.ok t/apr/uri...ok t/filter/case...ok t/filter/case_inok t/filter/input_body.ok t/http11/basicauth..ok t/http11/chunkedok t/http11/post...ok t/modules/accessok t/modules/alias.ok t/modules/asis..ok t/modules/autoindex.ok t/modules/autoindex2ok t/modules/cache.ok t/modules/cgi...ok t/modules/dav...skipped all skipped: cannot find module 'HTTP::DAV' t/modules/deflate...ok 3/7 skipped: skipping 304/deflate tests without mod_cgi and httpd = 2.1.0 t/modules/digestok t/modules/dir...ok t/modules/env...ok t/modules/expires...ok t/modules/headers...ok t/modules/include...ok t/modules/info..ok t/modules/negotiation...ok t/modules/proxy.# Failed test 1 in t/modules/proxy.t at line 15 # Failed test 2 in t/modules/proxy.t at line 16 # Failed test 3 in t/modules/proxy.t at line 20 # Failed test 4 in t/modules/proxy.t at line 21 # Failed test 5 in t/modules/proxy.t at line 24 # Failed test 6 in t/modules/proxy.t at line 25 # Failed test 7 in t/modules/proxy.t at line 29 # Failed test 8 in t/modules/proxy.t at line 30 # Failed test 9 in t/modules/proxy.t at line 44 # Failed test 12 in t/modules/proxy.t at line 57 # Failed test 13 in t/modules/proxy.t at line 58 FAILED tests 1-9, 12-13 Failed 11/13 tests, 15.38% okay
Re: authz: file-group ugliness
On Tuesday 25 October 2005 00:29, you wrote: This would be OK except that there is a bigger problem that I looked into trying to fix at one point but never completed it. The problem is the duplication of authorization types. Currently we have both mod_authz_groupfile and mod_authz_dbm implementing the types group and file-group. This causes a problem because if both of these modules are loaded and the configuration contains the directive: require group foo or require file-group which authorization module handles it? Well it seems to be completely dependant on load order and/or the use of the directives AuthzXXXAuthoritative. In addition to implementing an optional function in mod_authz_owner to get the owner id, all authorization types should probably be renamed to be unique. group - mod_authz_groupfile dbm-group - mod_authz_dbm dbd-group - mod_authz_dbd ldap-group - mod_authnz_ldap (already done) etc... thoughts on this...? Well, AFAICS that ambiguity only really kicks in if you have both an AuthGroupFile and an AuthDBMGroupFile, which is something that would be equally(?) problematic in 1.x/2.0. Ugly - yes. Totally broken - no. Unless I'm missing something? That still leaves an aura of ambiguity hanging around AuthAuthoritative. Perhaps a better solution would be to replace that with something like AuthOrder user group dbm-group which specifies an order of authz checks, and makes the last one 'authoritative' in terms of the old logic. Of course that still leaves file-group looking lonely. Maybe what that wants is a provider from authz_[file|dbm|dbd|ldap|etc] ? -- Nick Kew
Re: authz: file-group ugliness
AuthOrder user group dbm-group which specifies an order of authz checks, and makes the last one 'authoritative' in terms of the old logic. Of course that still leaves file-group looking lonely. Maybe what that wants is a provider from authz_[file|dbm|dbd|ldap|etc] ? Or go back to this naming concept floating at one point: require group ldap:foo which solves this class of problems (but kills the failover part; i.e. getting a group check done in ldap if possible; but fall trough to htpasswd if all is down). Dw
ProxyPassReverseCookieDomain in 2.0?
The patch in PR 10722 seems to be very widely referred to (perhaps widely used as well ;) ). Are there any known issues with that patch? Is there any technical reason why it couldn't be applied to 2.0?
Gentoo (Was: mod_python 3.2.3b available for testing)
Hmmm... Looking at /usr/lib/python2.4/httplib.py, sock.readline() gets an EOF upon reading the first byte. Do you see anything in the error logs associated with this, like a segfault? To make it easier to isolate, try editing test.py to comment out all other tests and just leave this one. Look for a line that looks like: perRequestSuite.addTest(PerRequestTestCase(test_req_headers_out)) and comment out every other test in this block but this one, then rerun it. At the end you should have a log file in the logs directory, hopefully it will contain a clue. Thanks! On Tue, 25 Oct 2005, Dominic Wong wrote: -1 for Gentoo Linux 2.6.13-gentoo-r3 Apache 2.0.54 Python 2.4.1 * Testing req.headers_out connect: (127.0.0.1, 32873) send: 'GET / HTTP/1.1\r\nAccept-Encoding: identity\r\nHost: test_req_headers_out:32873\r\n\r\n' reply: '' E == ERROR: test_req_headers_out (__main__.PerRequestTestCase) -- Traceback (most recent call last): File test.py, line 597, in test_req_headers_out response = conn.getresponse() File /usr/lib/python2.4/httplib.py, line 863, in getresponse response.begin() File /usr/lib/python2.4/httplib.py, line 333, in begin version, status, reason = self._read_status() File /usr/lib/python2.4/httplib.py, line 297, in _read_status raise BadStatusLine(line) BadStatusLine --
rproxy close_wait high cpu
Hi,
I am running solaris 8 with apache 2.0.53 over openssl 0.9.7 as a reverse
proxy which terminates and reestablishes SSL to the backend. I run the worker
mpm with 100 threads per process. The server has minimal load and uses a
crypto card. The build is pretty minimal and runs in a gateway environment.
I have had alot of issues with processes going into a high cpu state. These
are always associated with close_wait state connections and nearly all the
time all the connections are close_wait. Would this suggest something shared
is affecting all connections/threads in the process?
After trolling through 50Gb of snoop dumps I have found that the latest appear
associated with an outbound SSL session that does not fully establish. These
outbound connections receive the server certificate and should send the
client key/cipher exchange but nothing follows. The client to proxy session
is normal and the request has been received by the proxy, the proxy does not
establish SSL properly to the server and as such the proxy does not forward
the request.
In the mean time the client and server ends time out (120s approx) and send a
fin which the proxy acks. In both instances the proxy does not return a fin,
nor does it timeout. At some point the process goes high CPU. This is very
repeatable on a server with a load of around 10-15 connections per second and
may occur on average 1-2 times a day. Unfortunately this thing is killing us
on a highly political service.
While it appears SSL is the cause, apache does not seem to be handling the
situation very well. It looks like apache knows it has data to send to the
server and data to return to the client so it does not close it's side of the
socket. At some point it must go into some sort of loop trying to recover I
guess.
I can't recall truss returning anything on these reverse proxy runaway
processes but I managed to get a truss of a forward proxy using heaps of
memory. It looks like apache is not checking the return value on it's write.
From memory in this instance there was no longer an inside connection but
apache was still trying to write to one. The forward proxy servers also
suffer from close_waits when using huge memory but do not suffer from high
cpu. I am thinking the same kind of issue may exist with the reverse proxy
where it loops to read/write a closed socket without checking the return
value resulting in the high cpu.
I have now turned on debug logging for the SSL diag but does anyone have any
idea what may be going on here with apache and the high cpu? When does the
connection timer start, before the connection is attempted or after it is
established? Is there any more info you need?
Thanks,
Jon
Forward Proxy stuff
###
16786: writev(128, 0x7440C860, 6) Err#32 EPIPE
16786: write(6, 0x7440A510, 99)= 99
16786: [ T u e A p r 1 9 0 8 : 2 7 : 3 1 2 0 0 5 ] [ i n f o
16786: ] ( 3 2 ) B r o k e n p i p e : c o r e _ o u t p u t _ f
16786: i l t e r : w r i t i n g d a t a t o t h e n e t w o
16786: r k\n
16786: lwp_sigredirect(0, SIGPIPE, 0x) = 0
16786: poll(0x7440C3C0, 1, 30) = 1
16786: read(131, C9 nF216 R 08DF303CFE7 F.., 8000) = 1360
16786: poll(0x7440C3C0, 1, 30) = 1
16786: read(131, 11 1 # ; GF9FD + T04 e R.., 8000) = 1360
16786: poll(0x7440C3C0, 1, 30) = 1
16786: read(131, 10 91C f94 I93D2A6CD15 {.., 8000) = 1360
16786: poll(0x7440C3C0, 1, 30) = 1
16786: read(131, AEE8C78F9504B8 VF607918C.., 8000) = 1360
16786: poll(0x7440C3C0, 1, 30) = 1
16786: read(131, 0 r K\0 UB0A0\fF3C8 l93.., 8000) = 1360
16786: poll(0x7440C3C0, 1, 30) = 1
16786: read(131, \ `1EA4D51BCF % /A7 .F3.., 8000) = 1360
16786: signotifywait() = 13
16786: writev(128, 0x7440C860, 6) Err#32 EPIPE
16786: write(6, 0x7440A510, 99)= 99
16786: [ T u e A p r 1 9 0 8 : 2 7 : 3 2 2 0 0 5 ] [ i n f o
16786: ] ( 3 2 ) B r o k e n p i p e : c o r e _ o u t p u t _ f
16786: i l t e r : w r i t i n g d a t a t o t h e n e t w o
16786: r k\n
16786: lwp_sigredirect(0, SIGPIPE, 0x) = 0
16786: poll(0x6DA063C0, 1, 30) = 1
16786: read(45, 11BE K1501 w01C1 = + Z X.., 8000)= 4080
16786: signotifywait() = 13
16786: writev(70, 0x6DA06860, 5) Err#32 EPIPE
16786: write(6, 0x6DA04510, 99)= 99
16786: [ T u e A p r 1 9 0 8 : 2 7 : 3 3 2 0 0 5 ] [ i n f o
16786: ] ( 3 2 ) B r o k e n p i p e : c o r e _ o u t p u t _ f
16786: i l t e r : w r i t i n g d a t a t o t h e n
Re: authz: file-group ugliness
Dirk-Willem van Gulik said: Or go back to this naming concept floating at one point: require group ldap:foo which solves this class of problems (but kills the failover part; i.e. getting a group check done in ldap if possible; but fall trough to htpasswd if all is down). This should work if memory serves: require ldap:foo require file:foo satisfy any Regards, Graham --
Mapping proxy inbound to outbound connections
Hi, I want to tie together the inbound and outbound connections for a forward or reverse proxy session. I figured I would add the source ports to the log which would enable me to track the connections through firewall logs etc. based on addressing/port combinations. I was looking at writing a module/ filter to do this. Would this be possible and the best way to go or would there be an easier way? Thanks, Jon
Apache with SCTP streams.
Hello, I've been working on this patch to make apr and httpd work with SCTP streams. Stream Control Transmission Protocol (SCTP - RFC2960) is a transport layer protocol capable of providing reliable (in-order, no loss, no duplicates, no error) message oriented service to application. Other interesting features of SCTP include multistreaming (many logical pipes in 1 SCTP association to transfer independent data like web objects without head of line blocking problem) and multihoming (ability to support more than 1 interface/IP address at a SCTP endpoint). The idea was to enable httpd to receive HTTP request on a particular SCTP stream and send the HTTP response on the same stream. Using different SCTP streams for independent objects might improve performance (preventing HOL as mentioned above). apr-0.9.2 included recognition and support for SCTP from Randall Stewart. I did my changes on top of this. To give an outline of the implementation with the files involved: APR: o I created apr_socket_send_sctp and apr_socket_recv_sctp which take an extra parameter - SCTP stream id. The recv function uses recvmsg function call and gets the SCTP stream id on which the request came in. Similarly, sendmsg call is used in apr_socket_send_sctp (sendrecv.c in network_io/unix). o I didnt want to change the signature of any other function so I decided to use buckets to pass the stream id info to and fro. The socket bucket read puts the stream id (from socket recv) in a heap bucket and the caller takes the responsibility of retrieving this. (apr_buckets_socket.c, apr_brigade.c). HTTPD: o core_input_filter retrieves and stores the stream id in a field in the core_net_rec, which is used by core_output_filter-APR while sending response. o Also, I changed Listen directive to take the transport layer protocol as an extra argument so that web admin can choose SCTP or TCP. Currently, I have this patch working for httpd-2.0.55/apr-0.9.6. Would appreciate any feedback, Preethi PS: Should I send this mail to apr dev mailing list as well or will that be spamming?
configurable: add referrer to error logs
If we can determine the referer, we log it as well on all calls to log error. Can we make this configurable? It's rather annoying in a lot of cases. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: mod_python 3.2.3b available for testing
This may be a Python Windows thing, but it shows up in mod_python: When using util.FieldStorage on multipart/form-data encoded POST data containing a file, in Linux a field.file will yield a file object (actually a subclass of file), but in Windows you have to get the file object through field.file.file. This probably has something to do with the fact that Windows' implementation of tempfile.TemporaryFile is different from Linux, but it should be made consistent in the mod_python interface. Nick Jim Gallacher wrote: A new mod_python 3.2.3 beta tarball is now available for testing. A Windows binary is also available. This release is similar to 3.2.2b but fixes a couple a small issues where a non-threaded python is used. Here are the rules: In order for a file to be officially announced, it has to be tested by developers on the dev list. Anyone subscribed to this list can (and should feel obligated to :-) ) test it, and provide feedback *to _this_ list*! (Not the [EMAIL PROTECTED] list, and preferably not me personally). The files are (temporarily) available here: http://www.modpython.org/dist/ Please download it, then do the usual $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install Then (as non-root user!) $ cd test $ python test.py And see if any tests fail. If they pass, send a +1 to the list, if they fail, send the details (the versions of OS, Python and Apache, the test output, and suggestions, if any). Thank you, Jim Gallacher
Re: mod_python 3.2.3b available for testing
More info: python 2.4.2 on Linux: import tempfile t = tempfile.TemporaryFile() t open file 'fdopen', mode 'w+b' at 0xb7df07b8 type(t) type 'file' dir(t) ['__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', '__init__', '__iter__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', 'close', 'closed', 'encoding', 'fileno', 'flush', 'isatty', 'mode', 'name', 'newlines', 'next', 'read', 'readinto', 'readline', 'readlines', 'seek', 'softspace', 'tell', 'truncate', 'write', 'writelines', 'xreadlines'] python 2.4.1 on windows: import tempfile t = tempfile.TemporaryFile() t open file 'fdopen', mode 'w+b' at 0x0099FBA8 type(t) type 'instance' dir(t) ['__doc__', '__getattr__', '__init__', '__module__', '__repr__', 'close_called', 'file', 'name'] So this is an inconsistency within Python. Should mod_python attempt to correct it, or just claim a Python bug? Nick Nick wrote: This may be a Python Windows thing, but it shows up in mod_python: When using util.FieldStorage on multipart/form-data encoded POST data containing a file, in Linux a field.file will yield a file object (actually a subclass of file), but in Windows you have to get the file object through field.file.file. This probably has something to do with the fact that Windows' implementation of tempfile.TemporaryFile is different from Linux, but it should be made consistent in the mod_python interface. Nick Jim Gallacher wrote: A new mod_python 3.2.3 beta tarball is now available for testing. A Windows binary is also available. This release is similar to 3.2.2b but fixes a couple a small issues where a non-threaded python is used. Here are the rules: In order for a file to be officially announced, it has to be tested by developers on the dev list. Anyone subscribed to this list can (and should feel obligated to :-) ) test it, and provide feedback *to _this_ list*! (Not the [EMAIL PROTECTED] list, and preferably not me personally). The files are (temporarily) available here: http://www.modpython.org/dist/ Please download it, then do the usual $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install Then (as non-root user!) $ cd test $ python test.py And see if any tests fail. If they pass, send a +1 to the list, if they fail, send the details (the versions of OS, Python and Apache, the test output, and suggestions, if any). Thank you, Jim Gallacher
Re: authz: file-group ugliness
Dirk-Willem van Gulik wrote: AuthOrder user group dbm-group which specifies an order of authz checks, and makes the last one 'authoritative' in terms of the old logic. Of course that still leaves file-group looking lonely. Maybe what that wants is a provider from authz_[file|dbm|dbd|ldap|etc] ? Or go back to this naming concept floating at one point: require group ldap:foo which solves this class of problems (but kills the failover part; i.e. getting a group check done in ldap if possible; but fall trough to htpasswd if all is down). Or not... why not require group ldap:foo dbm:bar bash where bash would be a match against any provider, while foo would be specific to ldap, and bar would be specific to dbm?
Re: mod_python 3.2.3b available for testing
This behaviour has been with Python for quite a while, so claiming it's simply a Python bug will be the same as declaring we don't support Windows. Our company's software that runs on Windows and uses mod_python simply patches util.py with the following change: 227c227 if isinstance(item.file, FileType): --- if isinstance(item.file, FileType) or (hasattr(item.file, 'file') and isinstance(item.file.file, FileType)): I haven't tried this with mp32 yet (we're still running on Python 2.3 and I haven't had time to investigate how to compile mp on Windows), but on 3.0/3.1 it appears to work just fine for our customers. Best regards, Indrek Järve Inversion Software OÜ Nick wrote: More info: python 2.4.2 on Linux: import tempfile t = tempfile.TemporaryFile() t open file 'fdopen', mode 'w+b' at 0xb7df07b8 type(t) type 'file' dir(t) ['__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', '__init__', '__iter__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', 'close', 'closed', 'encoding', 'fileno', 'flush', 'isatty', 'mode', 'name', 'newlines', 'next', 'read', 'readinto', 'readline', 'readlines', 'seek', 'softspace', 'tell', 'truncate', 'write', 'writelines', 'xreadlines'] python 2.4.1 on windows: import tempfile t = tempfile.TemporaryFile() t open file 'fdopen', mode 'w+b' at 0x0099FBA8 type(t) type 'instance' dir(t) ['__doc__', '__getattr__', '__init__', '__module__', '__repr__', 'close_called', 'file', 'name'] So this is an inconsistency within Python. Should mod_python attempt to correct it, or just claim a Python bug? Nick Nick wrote: This may be a Python Windows thing, but it shows up in mod_python: When using util.FieldStorage on multipart/form-data encoded POST data containing a file, in Linux a field.file will yield a file object (actually a subclass of file), but in Windows you have to get the file object through field.file.file. This probably has something to do with the fact that Windows' implementation of tempfile.TemporaryFile is different from Linux, but it should be made consistent in the mod_python interface. Nick Jim Gallacher wrote: A new mod_python 3.2.3 beta tarball is now available for testing. A Windows binary is also available. This release is similar to 3.2.2b but fixes a couple a small issues where a non-threaded python is used. Here are the rules: In order for a file to be officially announced, it has to be tested by developers on the dev list. Anyone subscribed to this list can (and should feel obligated to :-) ) test it, and provide feedback *to _this_ list*! (Not the [EMAIL PROTECTED] list, and preferably not me personally). The files are (temporarily) available here: http://www.modpython.org/dist/ Please download it, then do the usual $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install Then (as non-root user!) $ cd test $ python test.py And see if any tests fail. If they pass, send a +1 to the list, if they fail, send the details (the versions of OS, Python and Apache, the test output, and suggestions, if any). Thank you, Jim Gallacher
Re: authz: file-group ugliness
Explain this a little further because I am a little confused. What do you intend to happen when a directive like: require group ldap:foo dbm:bar bash is issued? The problem here is the confusion as to which module is handling 'group'. In order for this to work, every authorization type needs to be unique which probably means that they need to be prefixed with the authorization handler name require file-group somefilegroup require ldap-group cn=someldapgroup,o=whatever require dbm-group somedbmgroup Then as we discussed a few weeks back, Satisfy any|all would have to be refactored to deal with authorization types rather than just the basic access control. Or am I missing something?? Brad On 10/25/2005 at 9:47:31 am, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Or not... why not require group ldap:foo dbm:bar bash where bash would be a match against any provider, while foo would be specific to ldap, and bar would be specific to dbm?
[PATCH] Add VIRTUAL_DOCUMENT_ROOT variable
The attached patch adds the VIRTUAL_DOCUMENT_ROOT so the
VirtualDocumentRoot value is available to test for dynamic virtual
hosts. The patch is against 2.0.55.
http://am-productions.biz/docs/patch-modules_mappers_mod_vhost_alias.c
--
Anish Mistry
[EMAIL PROTECTED]
AM Productions http://am-productions.biz/
--- modules/mappers/mod_vhost_alias.c.orig Fri Feb 4 15:21:18 2005
+++ modules/mappers/mod_vhost_alias.c Sat Oct 22 14:39:52 2005
@@ -259,12 +259,14 @@
int ndots;
char buf[HUGE_STRING_LEN];
-char *dest, last;
+char *dest, last, *path;
int N, M, Np, Mp, Nd, Md;
const char *start, *end;
const char *p;
+ apr_table_t *e;
+ e = r-subprocess_env;
ndots = 0;
dots[ndots++] = name-1; /* slightly naughty */
@@ -373,11 +375,20 @@
}
if (r-filename) {
+ path = apr_pstrcat(r-pool, r-filename, buf, NULL);
r-filename = apr_pstrcat(r-pool, r-filename, buf, uri, NULL);
}
else {
+ path = apr_pstrcat(r-pool, buf, NULL);
r-filename = apr_pstrcat(r-pool, buf, uri, NULL);
}
+
+if(apr_table_get(e, VIRTUAL_DOCUMENT_ROOT) == NULL)
+apr_table_addn(e, VIRTUAL_DOCUMENT_ROOT, path);
+else
+apr_table_set(e, VIRTUAL_DOCUMENT_ROOT, path);
+
+
}
static int mva_translate(request_rec *r)
pgp049gphnzfX.pgp
Description: PGP signature
Re: rproxy close_wait high cpu
Jon Snow wrote: Hi, I am running solaris 8 with apache 2.0.53 over openssl 0.9.7 as a reverse proxy which terminates and reestablishes SSL to the backend. I run the worker mpm with 100 threads per process. The server has minimal load and uses a crypto card. The build is pretty minimal and runs in a gateway environment. I have had alot of issues with processes going into a high cpu state. These are always associated with close_wait state connections and nearly all the time all the connections are close_wait. Would this suggest something shared is affecting all connections/threads in the process? Jon - first try bumping to 2.0.55, and secondly apply two patches, http://issues.apache.org/bugzilla/attachment.cgi?id=16744 fixes a flaw in proxy body handling/forwarding corruption, and http://people.apache.org/~wrowe/httpd-2.0-proto-timeout.patch fixes the timeout upon connection, as opposed to leaving the initial connection socket as blocking or nonblocking, no timeout. see if these help resolve your proxy situation. Bill
NameVirtualHosts SSL
Hi everyone, Firstly, this is a topic which may have been endlessly covered before, in which case I apologise and will go down in flames... But having referred to the 2.0 docs (well, more like the FAQ) at http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts2 I had a thought about the viability of using SSL with multiple name-based virtual hosts (on one IP address). The docs at the URL given above effectively say that hosting more than one SSL-enabled site using name-based virtual hosting is impossible, as it is only after the SSL envelope has been decrypted that the server can determine the host value and match this with the ServerName or ServerAlias. My question is why the server couldn't do some sort of reverse-lookup on its register of SSL certificates that are in use. Surely the server knows which certificate it is using to service the request (or else it wouldn't be able to decrypt its contents) and hence work out which virtual host uses that certificate? This approach means of course that each name-based virtual host would have to use a different certificate - but as those sites are more than likely on different domains the certificates would necessarily be different. Cheers guys, Great server. Mike
Re: Apache with SCTP streams.
On 10/25/2005 04:14 PM, Preethi Natarajan wrote: Hello, I've been working on this patch to make apr and httpd work with SCTP streams. Thanks for bringing this to the dev list. Thanks to Joe for making a full stop comment in buzilla to end the discussion there. For all that are interested in the (short) history on bugzilla: http://issues.apache.org/bugzilla/show_bug.cgi?id=37202 [..cut..] Currently, I have this patch working for httpd-2.0.55/apr-0.9.6. As Joe mentioned in its bugzilla comment, these changes must be done to the trunk first. So I would propose the following approach: 1. Provide your httpd part of the patch as a patch against trunk. 2. For the apr part of the patch I would suggest that you check if there is a released version of apr which handles your requirements without further patches. If there is no such released version of apr I guess the next step depends: If there is a version which should work (provides all features that you need) but actually does not work, I would regard this as a bug that should be fixed in this apr branch. So you should file an apr bug report including the fix patch. If you find no apr version that contains the features you need, I guess the apr patches should be also done against the trunk. I guess this would also require further discussion on the apr dev list. [..cut..] Regards Rüdiger
Re: NameVirtualHosts SSL
Kenevel wrote: My question is why the server couldn't do some sort of reverse-lookup on its register of SSL certificates that are in use. Surely the server knows which certificate it is using to service the request (or else it wouldn't be able to decrypt its contents) and hence work out which virtual host uses that certificate? The server knows exactly this, yes, but by then it is too late. The one-virtual-host-per-ip limitation is imposed by SSL, it has nothing to do with the webserver. There is an exception - if you use a wildcard certificate, you can run multiple virtual hosts on condition all the virtual hosts match the wildcard certificate. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: mod_python 3.2.3b available for testing
On Tue, 25 Oct 2005, Nick wrote: So this is an inconsistency within Python. Should mod_python attempt to correct it, or just claim a Python bug? I think both. In fact, three things (1) fix it to provide a consistent interface (2) still support the broken behaviour (3) claim it is a bug (in code comments, or perhaps even officially submit it to Python folks) Grisha
Re: NameVirtualHosts SSL
The one-virtual-host-per-ip limitation is imposed by SSL, it has nothing to do with the webserver. nitpick one-virtual-host-per-ip-and-port /nitpick There is an exception - if you use a wildcard certificate, you can run multiple virtual hosts on condition all the virtual hosts match the wildcard certificate. Another exception is if you don't care about the popup warning, and only use certificates for encryption, and not for identification of the webserver. Joost
Re: NameVirtualHosts SSL
Mike, On Oct 25, 2005, at 10:43 AM, Kenevel wrote: My question is why the server couldn't do some sort of reverse- lookup on its register of SSL certificates that are in use. Surely the server knows which certificate it is using to service the request (or else it wouldn't be able No, it doesn't. At the moment the SSL connection handshake occurs, the server needs to present a certificate to the client. The client has certain expectations of the Common Name (CN) field of the Distinguished Name (DN) string embedded in the certificate, so it is important that the server sends the correct certificate. At this point in the handshake, the server simply doesn't know enough of what the client wants, unless the client connects to a distinct IP address and the server has a virtual host configured on that IP address. Otherwise, the decision on which virtual host to send the request to is made way too late. to decrypt its contents) and hence work out which virtual host uses that certificate? This approach means of course that each name-based virtual host would have to use a different certificate - but as those sites are more than likely on different domains the certificates would necessarily be different. There is an extension to the TLS ClientHello that allows the client to indicate which servername it is trying to connect to: see http:// www.ietf.org/rfc/rfc3546.txt paragraph 3.1. However, I don't think mod_ssl currently supports this. mod_gnutls may be closer, you may want to check that out. Of course, until enough of your client base supports this extension it is perfectly useless to you. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: NameVirtualHosts SSL
Thanks Graham, Joost and Sander, I hadn't expected for Apache to need to know which virtual host to use so early in the request process. Cheers Mike From: Sander Temme [EMAIL PROTECTED] Reply-To: dev@httpd.apache.org To: dev@httpd.apache.org Subject: Re: NameVirtualHosts SSL Date: Tue, 25 Oct 2005 11:34:40 -0700 Mike, On Oct 25, 2005, at 10:43 AM, Kenevel wrote: My question is why the server couldn't do some sort of reverse- lookup on its register of SSL certificates that are in use. Surely the server knows which certificate it is using to service the request (or else it wouldn't be able No, it doesn't. At the moment the SSL connection handshake occurs, the server needs to present a certificate to the client. The client has certain expectations of the Common Name (CN) field of the Distinguished Name (DN) string embedded in the certificate, so it is important that the server sends the correct certificate. At this point in the handshake, the server simply doesn't know enough of what the client wants, unless the client connects to a distinct IP address and the server has a virtual host configured on that IP address. Otherwise, the decision on which virtual host to send the request to is made way too late. to decrypt its contents) and hence work out which virtual host uses that certificate? This approach means of course that each name-based virtual host would have to use a different certificate - but as those sites are more than likely on different domains the certificates would necessarily be different. There is an extension to the TLS ClientHello that allows the client to indicate which servername it is trying to connect to: see http:// www.ietf.org/rfc/rfc3546.txt paragraph 3.1. However, I don't think mod_ssl currently supports this. mod_gnutls may be closer, you may want to check that out. Of course, until enough of your client base supports this extension it is perfectly useless to you. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s
[PATCH] Multiple AuthUserFile support
Hi,
In the light of the issue reported by noodl at
http://eul113.eu.verio.net/~noodl/apache_issues.txt I decided to
implement multiple AuthUserFile support.
The behavior is the same as for a single AuthUserFile : the first line
matching the username is used, regardless of what's coming next.
The attached patch is against current httpd trunk (r328504), compiles
without warnings and has been tested successfully on my local Apache
build (Gcc 4.0.2, apr and apr-util from trunk, too).
** Since this is security related, and since I changed a little bit
the way check_password returns, I would be very pleased if this point
could be reviewed with particular attention. **
Regards,
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.
Index: modules/aaa/mod_authn_file.c
===
--- modules/aaa/mod_authn_file.c(revision 328504)
+++ modules/aaa/mod_authn_file.c(working copy)
@@ -28,33 +28,47 @@
#include mod_auth.h
+struct file_prefix {
+const char *file;
+};
+
typedef struct {
-char *pwfile;
+apr_array_header_t *pwfiles;
} authn_file_config_rec;
static void *create_authn_file_dir_config(apr_pool_t *p, char *d)
{
authn_file_config_rec *conf = apr_palloc(p, sizeof(*conf));
-conf-pwfile = NULL; /* just to illustrate the default really */
+conf-pwfiles = apr_array_make(p, 0, sizeof(struct file_prefix));
+
return conf;
}
static const char *set_authn_file_slot(cmd_parms *cmd, void *offset,
- const char *f, const char *t)
+ const char *f, const char *t)
{
+authn_file_config_rec *conf;
+struct file_prefix *item;
+
if (t strcmp(t, standard)) {
return apr_pstrcat(cmd-pool, Invalid auth file type: , t, NULL);
}
-return ap_set_file_slot(cmd, offset, f);
+conf = (authn_file_config_rec *)offset;
+
+/* Add the file to our AuthUserFile list */
+item = (struct file_prefix *)apr_array_push(conf-pwfiles);
+item-file = apr_pstrdup(cmd-pool, f);
+
+return NULL;
}
static const command_rec authn_file_cmds[] =
{
AP_INIT_TAKE12(AuthUserFile, set_authn_file_slot,
- (void *)APR_OFFSETOF(authn_file_config_rec, pwfile),
- OR_AUTHCFG, text file containing user IDs and passwords),
+ (void *)APR_OFFSETOF(authn_file_config_rec, pwfiles),
+ OR_AUTHCFG, text file containing user IDs and passwords),
{NULL}
};
@@ -68,44 +82,63 @@
ap_configfile_t *f;
char l[MAX_STRING_LEN];
apr_status_t status;
+struct file_prefix *files;
char *file_password = NULL;
+int i;
-status = ap_pcfg_openfile(f, r-pool, conf-pwfile);
+files = (struct file_prefix *)conf-pwfiles-elts;
-if (status != APR_SUCCESS) {
-ap_log_rerror(APLOG_MARK, APLOG_ERR, status, r,
- Could not open password file: %s, conf-pwfile);
-return AUTH_GENERAL_ERROR;
-}
+for (i=0; i conf-pwfiles-nelts; i++) {
+status = ap_pcfg_openfile(f, r-pool, files[i].file);
-while (!(ap_cfg_getline(l, MAX_STRING_LEN, f))) {
-const char *rpw, *w;
+if (status != APR_SUCCESS) {
+ap_log_rerror(APLOG_MARK, APLOG_ERR, status, r,
+ Could not open password file: %s, files[i].file);
+return AUTH_GENERAL_ERROR;
+}
-/* Skip # or blank lines. */
-if ((l[0] == '#') || (!l[0])) {
-continue;
+while (!(ap_cfg_getline(l, MAX_STRING_LEN, f))) {
+const char *rpw, *w;
+
+/* Skip # or blank lines. */
+if ((l[0] == '#') || (!l[0])) {
+continue;
+}
+
+rpw = l;
+w = ap_getword(r-pool, rpw, ':');
+
+if (!strcmp(user, w)) {
+file_password = ap_getword(r-pool, rpw, ':');
+break;
+}
}
+ap_cfg_closefile(f);
-rpw = l;
-w = ap_getword(r-pool, rpw, ':');
+ /* If the user was found in this file, check his
+ authentification */
+ if (file_password) {
+ status = apr_password_validate(password, file_password);
-if (!strcmp(user, w)) {
-file_password = ap_getword(r-pool, rpw, ':');
-break;
-}
+ /* If authentication succeeded, grant the access */
+ if (status == APR_SUCCESS) {
+ return AUTH_GRANTED;
+ }
+
+ /* Otherwise, deny the access immediately since only the
+ first entry found matching username is used */
+ else {
+ return AUTH_DENIED;
+ }
+ }
+
}
-ap_cfg_closefile(f);
if (!file_password) {
return AUTH_USER_NOT_FOUND;
}
-status = apr_password_validate(password,
Re: [PATCH] Multiple AuthUserFile support
--On October 26, 2005 1:49:15 AM +0200 Maxime Petazzoni [EMAIL PROTECTED] wrote: In the light of the issue reported by noodl at http://eul113.eu.verio.net/~noodl/apache_issues.txt I decided to implement multiple AuthUserFile support. I don't get it. mod_authn_alias is the solution here. Like so: --- AuthnProviderAlias file foo AuthUserFile conf/foo-user /AuthnProviderAlias AuthnProviderAlias file foo1 AuthUserFile conf/foo1-user /AuthnProviderAlias AuthBasicProvider foo foo1 --- So, I don't think extending AuthUserFile doesn't make sense; and the mod_authn_alias approach already works today... -- justin
Re: [PATCH] Multiple AuthUserFile support
* Justin Erenkrantz [EMAIL PROTECTED] [2005-10-25 17:05:57]: --On October 26, 2005 1:49:15 AM +0200 Maxime Petazzoni [EMAIL PROTECTED] wrote: In the light of the issue reported by noodl at http://eul113.eu.verio.net/~noodl/apache_issues.txt I decided to implement multiple AuthUserFile support. I don't get it. mod_authn_alias is the solution here. Like so: --- AuthnProviderAlias file foo AuthUserFile conf/foo-user /AuthnProviderAlias AuthnProviderAlias file foo1 AuthUserFile conf/foo1-user /AuthnProviderAlias AuthBasicProvider foo foo1 --- So, I don't think extending AuthUserFile doesn't make sense; and the mod_authn_alias approach already works today... -- justin You're right. But I don't think everybody as such an extensive knowledge of the authentication configuration. The example you gave may look simple to you, but I believe adding multiple AuthUserFile lines to a classic Basic Auth configuration schema is a lot more intuitive : AuthType Basic AuthName Developpement HTTPd server AuthUserFile /home/sam/.local/access.user AuthUserFile /home/sam/.local/access.user2 Require valid-user Just my 2 ¢, - Sam -- Maxime Petazzoni (http://www.bulix.org) -- gone crazy, back soon. leave message. signature.asc Description: Digital signature
Re: svn commit: r327945 - in /httpd/httpd/trunk: CHANGES modules/http/http_core.c modules/http/http_request.c server/mpm/experimental/event/event.c
On Oct 25, 2005, at 2:33 AM, Joe Orton wrote: httpd-test runs against the trunk are failing all over the place today, I guess caused by one of these changes... prefork is failing like: Failed TestStat Wstat Total Fail Failed List of Failed -- - t/modules/proxy.t13 11 84.62% 1-9 12-13 t/modules/proxy_balancer.t11 100.00% 1 t/modules/rewrite.t 225 22.73% 17-18 20-22 t/protocol/echo.t 255 65280 88 100.00% 1-8 t/security/CAN-2005-2700.t21 50.00% 1 ... plus almost all of t/ssl/* fail Sorry about that. I didn't have proxy and ssl compiled in when I regression-tested with httpd-test. I'll get started on a fix later this evening. Brian
