Just so everyone is clear, implementation of req.get_session() or its
equivalent has been deferred to version 3.3.
Graham Dumpleton wrote:
Some will know that I haven't been too keen on the way in which the
proposed new req.get_session() method was being implemented. My concerns
were that it
On Mon, 8 Aug 2005, Jim Gallacher wrote:
I had to double escape the r, ie \\\release to make it work. Grisha, did
you generate the docs on BSD before, and if so is the BSD sed different?
Yes, it was always done on FreeBSD before - it is quite likely that the
sed is different More likely
I've committed the fix. For some reason JIRA is picking up the
subversion commits but not forwarding the message to the mailing list.
This issue can be closed.
Jim
Jim Gallacher (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-69?page=all ]
Jim Gallacher updated
Colm MacCarthaigh wrote:
On Mon, Aug 08, 2005 at 12:45:21AM +0200, [EMAIL PROTECTED] wrote:
Is a traversal really needed? What about going back the full path of the
header / data file to the cache root and removing each component on the
way by calling apr_dir_remove on each component until it
Parin Shah said:
- using make_sub_request, ap_sub_req_method_uri methods. these
functions create a new request_req for a sub request and they take
current request_req as one of the argument. but mod-cache-requester
may not have current request available.
I suspect the best idea here is to
At 05:15 AM 8/8/2005, Graham Leggett wrote:
Parin Shah said:
we can store the original request_req which was used when the page was
served from cache, and then use it as a parameter to the above method.
Is this approach is fine?
This isn't very clean, a request_req is just a structure, they
On Mon, Aug 08, 2005 at 10:33:47AM +0200, [EMAIL PROTECTED] wrote:
Is a traversal really needed? What about going back the full path of the
header / data file to the cache root and removing each component on the
way by calling apr_dir_remove on each component until it fails?
I'm not sure
On Mon, Aug 08, 2005 at 02:11:12PM +0200, [EMAIL PROTECTED] wrote:
What makes you think so? As previously stated this works on Unix systems and
according to MS API doc it (RemoveDirectory) should behave in the same manner
on Windows. I was not able to check the OS/2 code, as I found no
This problem is solved, in a much general manner in mod_ssl_error (see bug
35083 - http://nagoya.apache.org/bugzilla/show_bug.cgi?id=35083).
Could we include this soon ?
The only decision is about the inclusion:
- in the distribution, with an option
- as a separate module, with an option
- as a
It appears that Apache does not use the built-in mechanism
from OpenSSL for CRL validation, but it implements its own one(I guess
because the one from OpenSSL was not complete enough some time ago
?).
It also seems that OpenSSL CRL validation is now much more
complete (IDP, delta CRL,
Colm MacCarthaigh wrote:
On Mon, Aug 08, 2005 at 10:33:47AM +0200, [EMAIL PROTECTED] wrote:
[..cut..]
The patch is attached, and I've been testing it for the last few hours
without problem. The code is now running on ftp.heanet.ie. (along
with htcacheclean -t).
Looks very good to me.
Working on mpm stuff now, everytime I start apache with worker on trunk
, I get;
::1 - - [08/Aug/2005:11:56:58 +0100] GET / HTTP/1.0 200 3089 - - 1966
::1 - - [08/Aug/2005:11:56:59 +0100] GET / HTTP/1.0 200 3089 - - 3856
::1 - - [08/Aug/2005:11:57:00 +0100] GET / HTTP/1.0 200 3089 - - 2389
::1 -
On Mon, Aug 08, 2005 at 03:24:44PM +0100, Colm MacCarthaigh wrote:
Which is pretty confusing imo for administrators (it was for me), patch
gives the dummy connections a User-Agent: header, so that the
administrator can determine that they don't have some errant local
process;
Of course it's
Colm MacCarthaigh wrote:
On Mon, Aug 08, 2005 at 03:24:44PM +0100, Colm MacCarthaigh wrote:
Which is pretty confusing imo for administrators (it was for me), patch
gives the dummy connections a User-Agent: header, so that the
administrator can determine that they don't have some errant local
I thought may be putting together a release schedule would help making 3.2
closer to reality.
I would really like to see it out some time before the next ApacheCon US
(10-14 December). I've submitted a mod_python talk and if it gets
approved, it'd be nice to be able to discuss the new/fixed
Hi Grisha,
What do you want for the win32 version ? I regularly rebuild the win32
installer from the latest Subversion revision and put it there :
http://nicolas.lehuen.com/download/mod_python . Using this installer,
people can test and give their +1 / -1. Is that OK for you ?
Regards,
Colm MacCarthaigh wrote:
On Mon, Aug 08, 2005 at 03:24:44PM +0100, Colm MacCarthaigh wrote:
+srequest = apr_pstrcat(p, GET / HTTP/1.0\r\nUser-Agent: ,
+ ap_get_server_version(),
+(internal dummy connection)\r\n\r\n, NULL);
Shouldn't
On Mon, Aug 08, 2005 at 11:29:59AM -0400, Brian Akins wrote:
Colm MacCarthaigh wrote:
On Mon, Aug 08, 2005 at 03:24:44PM +0100, Colm MacCarthaigh wrote:
+srequest = apr_pstrcat(p, GET / HTTP/1.0\r\nUser-Agent: ,
+ ap_get_server_version(),
+
+1
On Jul 20, 2005, at 9:16 AM, Sander Temme wrote:
Two very small patches against 1.3.
First one, make ab default to the highest SSL version available:
Index: src/support/ab.c
===
--- src/support/ab.c(revision 125243)
+++
On Aug 8, 2005, at 12:37 AM, William A. Rowe, Jr. wrote:
Still looking for a vote on this fix to core for 1.3, preventing
modules from seeing an invalid C-L + T-E combination from the
client per RFC 2616. This does not apply to proxy (as implemented
now) but may affect other handlers as I
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36083.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Andreas Steinmetz said:
The problem is that you can't remove directories with htcacheclean
without generating race conditions wrt. httpd.
In this case the race in httpd should be fixed.
In theory, httpd should attempt to create the directory, then attempt to
move the file to that directory.
William A. Rowe, Jr. said:
Still looking for a vote on this fix to core for 1.3, preventing
modules from seeing an invalid C-L + T-E combination from the
client per RFC 2616. This does not apply to proxy (as implemented
now) but may affect other handlers as I noted below. The sanest
action
On Mon, Aug 08, 2005 at 04:42:09PM +0100, Colm MacCarthaigh wrote:
On Mon, Aug 08, 2005 at 11:29:59AM -0400, Brian Akins wrote:
maybe just make it static like:
static char *srequest = NULL;
or;
const char *srequest = GET / HTTP/1.0\r\n
User-Agent:
Colm MacCarthaigh wrote:
On Mon, Aug 08, 2005 at 10:33:47AM +0200, [EMAIL PROTECTED] wrote:
[..cut..]
O.k., I've merged our two patches, but I've changed a few things, tell
me if there's anothing you think is wrong;
I attached two further patches to your merged patch:
Graham Leggett wrote:
Andreas Steinmetz said:
The problem is that you can't remove directories with htcacheclean
without generating race conditions wrt. httpd.
In this case the race in httpd should be fixed.
In theory, httpd should attempt to create the directory, then attempt to
I have a bug I'd like to squash in mod_auth_ldap.c in 2.0 that doesn't
exist in 2.1/2.2 (non-existent authn_ldap_request_t req struct during
auth check)... since the module is experimental, can I assume CTR ?
Jim Jagielski wrote:
I have a bug I'd like to squash in mod_auth_ldap.c in 2.0 that doesn't
exist in 2.1/2.2 (non-existent authn_ldap_request_t req struct during
auth check)... since the module is experimental, can I assume CTR ?
+1
IMO, imposing RTC on experimental modules is counter
As I sit here debugging our home grown proxy code for 2.0, I wonder how long
until 2.2? We wrote our own proxy because the cool 2.1 stuff was not out at
the time. The new proxy stuff would be wonderful for us, but noone wants to
run alpha code in production. (However, we are quick to run
Bill Stoddard wrote:
Jim Jagielski wrote:
I have a bug I'd like to squash in mod_auth_ldap.c in 2.0 that doesn't
exist in 2.1/2.2 (non-existent authn_ldap_request_t req struct during
auth check)... since the module is experimental, can I assume CTR ?
+1
IMO, imposing RTC on
Akins, Brian wrote:
As I sit here debugging our home grown proxy code for 2.0, I wonder how long
until 2.2? We wrote our own proxy because the cool 2.1 stuff was not out at
the time. The new proxy stuff would be wonderful for us, but noone wants to
run alpha code in production. (However, we
At 03:36 PM 8/8/2005, Bill Stoddard wrote:
Jim Jagielski wrote:
I have a bug I'd like to squash in mod_auth_ldap.c in 2.0 that doesn't
exist in 2.1/2.2 (non-existent authn_ldap_request_t req struct during
auth check)... since the module is experimental, can I assume CTR ?
+1
IMO, imposing RTC on
Paul Querna wrote:
Bill Stoddard wrote:
Jim Jagielski wrote:
I have a bug I'd like to squash in mod_auth_ldap.c in 2.0 that doesn't
exist in 2.1/2.2 (non-existent authn_ldap_request_t req struct during
auth check)... since the module is experimental, can I assume CTR ?
+1
William A. Rowe, Jr. wrote:
At 03:36 PM 8/8/2005, Bill Stoddard wrote:
Jim Jagielski wrote:
I have a bug I'd like to squash in mod_auth_ldap.c in 2.0 that doesn't
exist in 2.1/2.2 (non-existent authn_ldap_request_t req struct during
auth check)... since the module is experimental, can I
Bill Stoddard wrote:
William A. Rowe, Jr. wrote:
At 03:36 PM 8/8/2005, Bill Stoddard wrote:
Jim Jagielski wrote:
I have a bug I'd like to squash in mod_auth_ldap.c in 2.0 that doesn't
exist in 2.1/2.2 (non-existent authn_ldap_request_t req struct during
auth check)... since the
On Monday, August 08, 2005 at 3:23 pm, in message
Yep, I'm +1 on RTC for both cache and ldap/.
Bill
Did you mean CTR?
Brad
Bill Stoddard wrote:
William A. Rowe, Jr. wrote:
At 03:36 PM 8/8/2005, Bill Stoddard wrote:
Jim Jagielski wrote:
I have a bug I'd like to squash in mod_auth_ldap.c in 2.0 that doesn't
exist in 2.1/2.2 (non-existent authn_ldap_request_t req struct during
auth check)... since the module is
+1 Deja vu, this thread sounds a lot like a discussion we had
during/post-ApacheCon 2004. I would still like to see the patches come through
trunk first just to make sure we don't miss something going forward. In the
case of auth_ldap and util_ldap, the 2.0 code base was never officially
On 09/08/2005, at 1:34 AM, Jim Gallacher wrote:
Anyway, have been thinking about this stuff on and off and have come
with an idea which might be worth pursuing.
...
I think this may have merit although I need to mull it over.
Would the session cache be on disk or in memory?
The cache would
On 09/08/2005, at 7:51 AM, Graham Dumpleton wrote:
Will it introduce new and exciting locking issues for accessing the
cache?
I don't think so, the caching is effectively done on a thread specific
basis only and thus where the lock synchronisation point for different
threads wanting to create
Any change that hasn't been released can be vetoed if a technical
explanation is given. If you don't have time to fix it immediately,
then the person who committed the change is required to back the
change out to the point where we are back to the prior release code.
If you don't like that,
Bill, if you spent more time making your changes understandable
by documenting what they change instead of various random things
totally unrelated to each patch, then maybe people like me could
review them. Also, it would help a great deal if you would make
a complete set of changes locally,
At 04:49 PM 8/8/2005, Brad Nicholes wrote:
+1 Deja vu, this thread sounds a lot like a discussion we had
during/post-ApacheCon 2004. I would still like to see the patches come
through trunk first just to make sure we don't miss something going forward.
+1; too many folks are focused on
--On August 8, 2005 1:46:30 PM -0700 Paul Querna [EMAIL PROTECTED]
wrote:
-1 (vote, not veto).
-1 as well.
It should be reviewed, regardless of being on applicable to 2.0. Put it
in the status file, just like everything else. I feel that being in
'experimental' is not a good excuse for
At 06:27 PM 8/8/2005, Roy T. Fielding wrote:
Any change that hasn't been released can be vetoed if a technical
explanation is given.
Roy; I -totally- agree with your position. However, emails going
back to 1997 of http://httpd.apache.org/dev/voting.html describe
a very specific process; votes
At 06:58 PM 8/8/2005, Roy T. Fielding wrote:
Bill, if you spent more time making your changes understandable
by documenting what they change instead of various random things
totally unrelated to each patch, then maybe people like me could
review them.
Without quoting you at length and spending
At 08:34 PM 8/8/2005, William A. Rowe, Jr. wrote:
I'M FUCKING SICK AND TIRED OF BEING ASKED TO BRING EACH SPECIFIC
REVIEWIER THEIR OWN SHINEY FUCKING ROCK.
FYI, I am NOT speaking to your comments exclusively, Roy, nor
Jeff's, nor anyone else's. This just one typical reaction
to being asked for
Akins, Brian wrote:
As I sit here debugging our home grown proxy code for 2.0, I wonder how long
until 2.2? We wrote our own proxy because the cool 2.1 stuff was not out at
the time. The new proxy stuff would be wonderful for us, but noone wants to
run alpha code in production. (However, we
On Aug 8, 2005, at 5:24 PM, William A. Rowe, Jr. wrote:
At 06:27 PM 8/8/2005, Roy T. Fielding wrote:
Any change that hasn't been released can be vetoed if a technical
explanation is given.
Roy; I -totally- agree with your position. However, emails going
back to 1997 of
I can't believe you guys are still debating the merits of RTC over CTR
after all this time. RTC killed the momentum in this project a long time
ago.
* Quality and stability are emergent properties, not processes:
Making releases is a natural step in the bug-fixing cycle. However,
the STATUS
50 matches
Mail list logo
