[ http://issues.apache.org/jira/browse/MODPYTHON-191?page=all ]
Graham Dumpleton updated MODPYTHON-191:
---
Fix Version/s: 3.3
This will now be addressed as part of code changes for MODPYTHON-200.
Tampering with signed cookies.
[ http://issues.apache.org/jira/browse/MODPYTHON-191?page=all ]
Work on MODPYTHON-191 started by Graham Dumpleton.
Tampering with signed cookies.
--
Key: MODPYTHON-191
URL: http://issues.apache.org/jira/browse/MODPYTHON-191
[ http://issues.apache.org/jira/browse/MODPYTHON-191?page=all ]
Graham Dumpleton reassigned MODPYTHON-191:
--
Assignee: Graham Dumpleton
Tampering with signed cookies.
--
Key: MODPYTHON-191
In mod_python, the session ID consists of 32 characters coming from the ranges
0-9 and a-f. At the moment the code will if it detects invalid characters in
the SID or it is the wrong size, raise a HTTP_INTERNAL_SERVER_ERROR exception.
if self._sid:
# Validate the sid *before*
Issac Goldstand [EMAIL PROTECTED] writes:
Philip M. Gollucci wrote:
[...]
Sadly, I don't think this can go into the 2.x series because of our
conversioning rules.
New features need new symbols. SVN gets around this by doing:
void foo (void)
void foo2 (int)
Can you elaborate? I didn't
Philip M. Gollucci wrote:
this one time in band camp Patrick Galbraith said on 10/29/06 16:26:
Dave,
Speaking of which - how do you use gdb with mod_perl/libapreq? I'm
used to using it and other debuggers (Visual Studio, etc, DDD with
gdb, Xcode) with mysqld and DBD::mysql, but how do you
Issac Goldstand [EMAIL PROTECTED] writes:
That's what I originally thought when told to do it this way, but its wrong.
RFC 3875 section 4.1.7 says
The server MUST set this variable; if the Script-URI does not include
a query component, the QUERY_STRING MUST be defined as an empty
Joe Schaefer [EMAIL PROTECTED] writes:
Why not just use GATEWAY_INTERFACE? That way we don't need to argue
about the actual adoption of RFC 3875 (not a standard) vs the original
(ambiguous) CGI spec.
Actually I took a peek around, and I think both IIS and Tomcat support
3875. So as long as
I'd like to get a sense from Win32 ppm users of mod_perl
and/or libapreq2 about the following. Right now in our
http://theoryx5.uwinnipeg.ca/ppms/
ppm repository, there's ppm packages for mod_perl
and libapreq2. The ones compatible with Apache/2.0 are
called mod_perl and libapreq2,
Justin Erenkrantz wrote:
I will also note that the mod_cache provider system has explicit
versioning, so any modifications to the providers should be
represented with a new version number. (i.e. providers for version
0 should work while offering new features in version 1-class
providers.) We
On 10/30/06, Issac Goldstand [EMAIL PROTECTED] wrote:
Can you clarify the above a bit? I don't understand what you're
referring to. Looking at the 2.2.3 tag, what versioning is currently in
place?
Look at disk_cache_register_hook.
/* cache initializer */
ap_register_provider(p,
Ruediger Pluem wrote:
Then you can easily just use
Proxy ajp://localhost:8009
ProxySet ...
/Proxy
It will define a 'known' worker.
There is no need for an additional directive.
Yes, this idea came also up to me after sending the mail.
It seems to be an acceptable solution for this
Justin Erenkrantz wrote:
On 10/30/06, Issac Goldstand [EMAIL PROTECTED] wrote:
Can you clarify the above a bit? I don't understand what you're
referring to. Looking at the 2.2.3 tag, what versioning is currently in
place?
Look at disk_cache_register_hook.
/* cache initializer */
Philip M. Gollucci wrote:
this one time in band camp Issac Goldstand said on 10/29/06 01:41:
If you're planning on rolling libapreq-2.09 soon, maybe we should
include the intial work done in /branches/enhanced-cgi/
http://svn.apache.org/repos/asf/httpd/apreq/branches/enhanced-cgi/
It seems
On Mon, October 30, 2006 7:58 am, Justin Erenkrantz wrote:
We have a real world case where the cache is expected to process a many
MB or many GB file completely, before sending that same response to the
network. This is too slow, and takes up too much RAM, resulting in a
broken response to
On Mon, October 30, 2006 4:54 am, William A. Rowe, Jr. wrote:
You mean sandboxes (at least that's what we normally refer to them as,
trunk/ IS the dev branch :) ...
I strongly disagree because MOST of the flaws in the HTTP/1.1
implementation,
mod_proxy and even mod_cache exist because the
Thanks Roy. So, the goals for mod_disk_cache as I see it:
A simple general-purpose disk cache which makes no assumptions about
speed of backend, speed of storage or speed of clients; is
single-threaded and does not involve any multi-process synchronisation
beyond open/O_EXCL. Specifically:
On Mon, October 30, 2006 12:07 pm, Joe Orton wrote:
Thanks Roy. So, the goals for mod_disk_cache as I see it:
A simple general-purpose disk cache which makes no assumptions about
speed of backend, speed of storage or speed of clients; is
single-threaded and does not involve any
On Mon, 30 Oct 2006 01:53:18 +0200
Graham Leggett [EMAIL PROTECTED] wrote:
The current expectation that it be possible to separate completely
the storing of the cached response and the delivery of the content is
broken.
Why is that?
(references to previous discussion will do, if applicable)
On Mon, Oct 30, 2006 at 12:18:30PM +0200, Graham Leggett wrote:
On Mon, October 30, 2006 12:07 pm, Joe Orton wrote:
1) cannot write entire response to disk for any content type before
sending anything to the client; filter acts by writing to cache and
client synchronously
Justin vetoed
On Mon, October 30, 2006 12:57 pm, Nick Kew wrote:
The current expectation that it be possible to separate completely
the storing of the cached response and the delivery of the content is
broken.
Why is that?
Because:
- the cache_body() hook is expected to swallow an entire brigade
On Mon, October 30, 2006 1:03 pm, Joe Orton wrote:
On Mon, October 30, 2006 12:07 pm, Joe Orton wrote:
1) cannot write entire response to disk for any content type before
sending anything to the client; filter acts by writing to cache and
client synchronously
Justin vetoed this.
Can we
On Mon, 30 Oct 2006 14:03:03 +0200 (SAST)
Graham Leggett [EMAIL PROTECTED] wrote:
On Mon, October 30, 2006 12:57 pm, Nick Kew wrote:
The current expectation that it be possible to separate completely
the storing of the cached response and the delivery of the content
is broken.
Why is
On Mon, October 30, 2006 2:44 pm, Nick Kew wrote:
Hang on! Where's the file coming from? If it's local and static,
what is mod_cache supposed to gain you? And if not, what put it
in a (single) file bucket before it reached mod_cache?
In the case of the person who reported this issue, the
Davi Arnaut wrote:
The solution consists of using the cache file as a output buffer by
splitting the buckets into smaller chunks and writing then to disk. Once
written (apr_file_write_full) a new file bucket is created with offset
and size of the just written buffer. The old bucket is deleted.
On Mon, October 30, 2006 4:44 pm, Brian Akins wrote:
Without having looked very much at the code, this approach sounds
feasible.
I'm still confused as to why we need the temporary brigade??? Why not
swap
the buckets?
The current cache (as in what is in trunk right now) does exactly that -
On 10/30/06, Issac Goldstand [EMAIL PROTECTED] wrote:
Looking at provider.c, a couple of questions spring to mind:
1) Why isn't this part of apr-util? (it seems similar to apr_optional.h
- just intended for vtables rather than functions, and with this version
info)
apr_optional is an ugly hack
On Mon, Oct 30, 2006 at 09:51:30AM -0700, Justin Erenkrantz wrote:
It would make
custom 3rd party modules easier to write too; we could define, say 1
as PROVIDER_ID_CUSTOM, making it easier to write add-ons to modules
which use the provider interface to just write new providers with that
On 10/30/06, Joe Orton [EMAIL PROTECTED] wrote:
A simple general-purpose disk cache which makes no assumptions about
speed of backend, speed of storage or speed of clients; is
single-threaded and does not involve any multi-process synchronisation
beyond open/O_EXCL. Specifically:
+1. I would
On 10/30/06, Joe Orton [EMAIL PROTECTED] wrote:
So here's another assumption to consider with this work...
I keep seeing people talk about the mod_cache interface as an
externally-visible API for which we must maintain API/ABI compatibility.
But mod_cache.h is not installed, so this API is not
Justin Erenkrantz wrote:
On 10/30/06, Issac Goldstand [EMAIL PROTECTED] wrote:
Looking at provider.c, a couple of questions spring to mind:
1) Why isn't this part of apr-util? (it seems similar to apr_optional.h
- just intended for vtables rather than functions, and with this version
info)
On Mon, Oct 30, 2006 at 10:26:18AM -0700, Justin Erenkrantz wrote:
On 10/30/06, Joe Orton [EMAIL PROTECTED] wrote:
1) cannot write entire response to disk for any content type before
sending anything to the client; filter acts by writing to cache and
client synchronously
My concern with
The existing 2.x store_body interface passed a brigade to the storage
provider's store_body() callback. It is impossible for the provider to
store all of such a brigade without consuming an arbitrary amount of
RAM, since the brigade may contain morphing buckets (a CGI/PIPE bucket
is the
On 10/30/06, Joe Orton [EMAIL PROTECTED] wrote:
On Mon, Oct 30, 2006 at 10:26:18AM -0700, Justin Erenkrantz wrote:
My concern with this is we should be careful not to teach the
providers about the fact that it is sitting in an output filter chain.
This is solvable if desired, but I'd like to
On 10/30/06, Joe Orton [EMAIL PROTECTED] wrote:
1) change the store_body interface to allow the storage provider direct
access to f-next, so it can flush buckets up the output filter chain
when they have been stored. As seen on trunk.
2) keep the interface as-is, but read buckets in mod_cache
Justin Erenkrantz wrote:
+1. I would prefer that all bells and whistles be kept out of
mod_disk_cache and we provide another alternative that has more
complex behaviors that scales a little better for those who care.
(That was the whole reason behind a versioned provider interface to
begin
Justin Erenkrantz wrote:
1) change the store_body interface to allow the storage provider direct
access to f-next, so it can flush buckets up the output filter chain
when they have been stored. As seen on trunk.
2) keep the interface as-is, but read buckets in mod_cache and partition
the
Am Montag, den 30.10.2006, 18:42 +0530 schrieb Manish Chakravarty:
Hi all,
I am developing a module on Apache 1.3. Can someone please tell me how
to increase the size of an Apache array manually?
Do i manually increment the nelts field?
If this works as on 2 you simply have to call
On 10/24/06, Graham Leggett [EMAIL PROTECTED] wrote:
For example, if you are using OpenLDAP, you need to set you CA
certificates using LDAPTrustedGlobalCert, and set your client certificates
on a per connection basis inside a directory and/or virtual host container
using LDAPTrustedClientCert.
On Mon, 30 Oct 2006 11:36:43 -0700
Justin Erenkrantz [EMAIL PROTECTED] wrote:
3) change the interface: deal with the buckets entirely in
mod_cache and just pass (char *,size_t) pairs to store_body
#3 gets my vote. I hate bucket brigades anyway. ;-)
-1 to doing that with local, static
On 10/30/2006 07:53 PM, Graham Leggett wrote:
Justin Erenkrantz wrote:
1) change the store_body interface to allow the storage provider direct
access to f-next, so it can flush buckets up the output filter chain
when they have been stored. As seen on trunk.
I am with Justin here. Dealing
Eric Covener wrote:
Some research shows only alpha releases of openldap even pretend to
allow the CERTFILE/KEYFILE on a per-connection (i.e. LDAP*) basis --
the latest stable and released levels (2.3.28, 2.3.27)
ldap_pvt_tls_set_option will explicitly bail out of the
CERTFILE/KEYFILE options
On 10/30/06, Nick Kew [EMAIL PROTECTED] wrote:
-1 to doing that with local, static files. And once you start
making exceptions to a rule, that becomes BAD complexity.
What exceptions are you talking about?
Everything would be treated as a char *, size_t pair. It's quite
simple, actually...
On 10/29/06, Ruediger Pluem [EMAIL PROTECTED] wrote:
On a related note, our practice with mod_jk is to route only *.jsp,
/servlet/*, and a few other URL patterns to Tomcat and let Apache handle
everything else. We also want to support load balancing with sticky
sessions, of course.
That
On 10/30/06, Graham Leggett [EMAIL PROTECTED] wrote:
Eric Covener wrote:
Some research shows only alpha releases of openldap even pretend to
allow the CERTFILE/KEYFILE on a per-connection (i.e. LDAP*) basis --
the latest stable and released levels (2.3.28, 2.3.27)
ldap_pvt_tls_set_option
On Tue, October 31, 2006 1:25 am, Eric Covener wrote:
Looks like the openldap 2.4 series (alpha) can support this by
requesting a new openssl CTX
(ldap_set_option(...,APR_LDAP_OPT_X_TLS_NEWCTX,...) but I had to
explicitly call openssl's SSL_library_init(); before ldap_set_option
or it died
46 matches
Mail list logo
