Olly Stephens wrote:
I'm using apreq2-2.08 with httpd-2.2.3 on solaris 10. It's a 64-bit build.
I was having the worst time getting this compiled on Solaris 10 using gcc
everything else
same as you. See the SVN trunk 'CHANGES' file for what I had to fix.
I'll look into duplicating this and
On Wed, 13 Sep 2006, Davi Arnaut wrote:
I'm working on this. You may want to check my proposal at
http://verdesmares.com/Apache/proposal.txt
Will it be possible to do away with one file for headers and one file
for body in mod_disk_cache with this scheme?
The thing is that I've been
Niklas Edmundsson wrote:
Will it be possible to do away with one file for headers and one file
for body in mod_disk_cache with this scheme?
This definitely has lots of advantages - however HTTP/1.1 requires that
it be possible to modify the headers on a cached entry independently of
the
Niklas Edmundsson wrote:
The stuff is used in production and seems stable, however I haven't had
any response to the first (trivial) patch sent so I don't know if
there's any interest in this.
Can you post the patch again? Also, if you attach it to a bugzilla
entry, it's less likely to get
I'm not sure I understand what you're trying to accomplish. If the
parse fails, why do you need the temp filename?
Brian McQueen wrote:
Better still I passed in the request_record as the context and saved
the information in the per request config structure for the module:
apreq_hook_t *
This looks familiar. I seem to remembering seeing patches for this a
few months back. Were they not committed to trunk? If not, is there
any reason why not? I'd hate to spend serious time making modifications
only to have to redo the work when this (pretty major) patchset gets
committed...
On Thu, 14 Sep 2006, Graham Leggett wrote:
Niklas Edmundsson wrote:
Will it be possible to do away with one file for headers and one file for
body in mod_disk_cache with this scheme?
This definitely has lots of advantages - however HTTP/1.1 requires that it be
possible to modify the
To facilitate the merging of our large mod_disk_cache fixup I will
send small patches that fix various bugs so that they can be applied
incrementally to trunk with relevant discussion limited to those
patches and me not having to respin entire patchsets due to trivial
fixes to patches like
On 9/13/06, Nick Kew [EMAIL PROTECTED] wrote:
On Wednesday 13 September 2006 22:31, Jeff Trawick wrote:
On 9/13/06, Nick Kew [EMAIL PROTECTED] wrote:
On Wednesday 13 September 2006 20:33, Ruediger Pluem wrote:
Wouldn't it make sense to return OK even if rv != APR_SUCCESS in the
case
On 14/09/2006, at 04:24, Niklas Edmundsson wrote:
On Wed, 13 Sep 2006, Davi Arnaut wrote:
I'm working on this. You may want to check my proposal at http://
verdesmares.com/Apache/proposal.txt
Will it be possible to do away with one file for headers and one
file for body in mod_disk_cache
-Ursprüngliche Nachricht-
Von: Jeff Trawick
Yes, I am supporting Rüdiger's proposition. Don't make up some HTTP
status code for the aborted-connection condition. We already have a
way to record this issue (%c).
I guess by %c you mean what is now %X in, mod_log_config, right?
On Thu, September 14, 2006 11:17 am, Niklas Edmundsson wrote:
To facilitate the merging of our large mod_disk_cache fixup I will
send small patches that fix various bugs so that they can be applied
incrementally to trunk with relevant discussion limited to those
patches and me not having to
On 9/14/06, Plüm, Rüdiger, VF EITO [EMAIL PROTECTED] wrote:
-Ursprüngliche Nachricht-
Von: Jeff Trawick
Yes, I am supporting Rüdiger's proposition. Don't make up some HTTP
status code for the aborted-connection condition. We already have a
way to record this issue (%c).
I
On 14/09/2006, at 04:39, Graham Leggett wrote:
Niklas Edmundsson wrote:
Will it be possible to do away with one file for headers and one
file for body in mod_disk_cache with this scheme?
This definitely has lots of advantages - however HTTP/1.1 requires
that it be possible to modify the
On Thu, September 14, 2006 1:42 pm, Davi Arnaut wrote:
This is not a top priority since actually there is no complete
support for it in mod_cache (partial responses and such), but it
would be nice to have it.
HTTP/1.1 compliance is mandatory for the cache. If it doesn't work now, it
needs to
On 14/09/2006, at 05:08, Issac Goldstand wrote:
This looks familiar. I seem to remembering seeing patches for this a
few months back. Were they not committed to trunk? If not, is there
any reason why not? I'd hate to spend serious time making
modifications
only to have to redo the work
On Thu, 14 Sep 2006, Davi Arnaut wrote:
On 14/09/2006, at 04:24, Niklas Edmundsson wrote:
On Wed, 13 Sep 2006, Davi Arnaut wrote:
I'm working on this. You may want to check my proposal at
http://verdesmares.com/Apache/proposal.txt
Will it be possible to do away with one file for headers
On 14/09/2006, at 08:48, Graham Leggett wrote:
On Thu, September 14, 2006 1:42 pm, Davi Arnaut wrote:
This is not a top priority since actually there is no complete
support for it in mod_cache (partial responses and such), but it
would be nice to have it.
HTTP/1.1 compliance is mandatory
On 14/09/2006, at 09:06, Niklas Edmundsson wrote:
On Thu, 14 Sep 2006, Davi Arnaut wrote:
On 14/09/2006, at 04:24, Niklas Edmundsson wrote:
On Wed, 13 Sep 2006, Davi Arnaut wrote:
I'm working on this. You may want to check my proposal at http://
verdesmares.com/Apache/proposal.txt
Will
On Thu, September 14, 2006 2:07 pm, Davi Arnaut wrote:
The cache is required to send to the client the most up-to-date
response, it doesn't mean it must cache it.
As I recall once cached, if an entry is stale and is revalidated, the
headers coming back with the 304 Not Modified must replace
On 14/09/2006, at 09:21, Davi Arnaut wrote:
On 14/09/2006, at 09:06, Niklas Edmundsson wrote:
On Thu, 14 Sep 2006, Davi Arnaut wrote:
On 14/09/2006, at 04:24, Niklas Edmundsson wrote:
On Wed, 13 Sep 2006, Davi Arnaut wrote:
I'm working on this. You may want to check my proposal at
On Thu, 14 Sep 2006, Graham Leggett wrote:
On Thu, September 14, 2006 11:17 am, Niklas Edmundsson wrote:
To facilitate the merging of our large mod_disk_cache fixup I will
send small patches that fix various bugs so that they can be applied
incrementally to trunk with relevant discussion
On Thu, 14 Sep 2006, Davi Arnaut wrote:
I'm working on this. You may want to check my proposal at
http://verdesmares.com/Apache/proposal.txt
Will it be possible to do away with one file for headers and one file
for body in mod_disk_cache with this scheme?
A separate branch *would* really be nice; as I've got my own changes to
mod_cache that I'm working on (support for offline-browsing caching,
if upstream servers aren't available + attempt to cache other normally
non-cachable content (POSTs, etc)). Regardless of whether it's fit to
be
On Thu, 14 Sep 2006, Graham Leggett wrote:
On Thu, September 14, 2006 2:41 pm, Niklas Edmundsson wrote:
Yup. The situation seems to be complicated somewhat by Davi working on
the cache-thingies, and doing more than just poking around in the
mod_cache infrastructure...
However, it seems that
There is a lot of confusion where the users think that
simply adding the stickysession param to the http worker
attribute *adds* the required sticky session info (cookie).
I'm looking into adding functionality that actually
does that and therefore avoiding this large and common
misconception.
Jim Jagielski wrote:
There is a lot of confusion where the users think that
simply adding the stickysession param to the http worker
attribute *adds* the required sticky session info (cookie).
I'm looking into adding functionality that actually
does that and therefore avoiding this large and
Paul Querna wrote:
Jim Jagielski wrote:
There is a lot of confusion where the users think that
simply adding the stickysession param to the http worker
attribute *adds* the required sticky session info (cookie).
I'm looking into adding functionality that actually
does that and therefore
Paul Querna wrote:
Jim Jagielski wrote:
There is a lot of confusion where the users think that
simply adding the stickysession param to the http worker
attribute *adds* the required sticky session info (cookie).
I'm looking into adding functionality that actually
does that and
Jim Jagielski wrote:
There is a lot of confusion where the users think that
simply adding the stickysession param to the http worker
attribute *adds* the required sticky session info (cookie).
I'm looking into adding functionality that actually
does that and therefore avoiding this large and
Jim Jagielski wrote:
Paul Querna wrote:
Jim Jagielski wrote:
There is a lot of confusion where the users think that
simply adding the stickysession param to the http worker
attribute *adds* the required sticky session info (cookie).
I'm looking into adding functionality that actually
does
Paul Querna wrote:
Jim Jagielski wrote:
Paul Querna wrote:
Jim Jagielski wrote:
There is a lot of confusion where the users think that
simply adding the stickysession param to the http worker
attribute *adds* the required sticky session info (cookie).
I'm looking into adding
I used:
APREQ2_ReadLimit 5
hopefully as only a temporary solution.
I need to be able to set the ReadLimit dynamically
if at all possible. Is it?
Should I have opened this thread on the mod_perl list instead?
Thanks,
Boysenberry
boysenberrys.com | habitatlife.com | selfgnosis.com
I'm working on an OpenID access control using mod_python. As part of the
OpenID protocol, our code redirects (302) attempted access to a login page.
Works Great.
However. If I try to use mod_autoindex to view a directory, and some of the
files in that directory have OpenID access control
On Sep 14, 2006, at 9:37 AM, Jim Jagielski wrote:
That's what I'm thinking, sort of like an 'autostickysession'
attribute.
We could even have it default to cookies but add something like
'autostickysession=url' to force URL rewriting and adding a tag
to the end of the URL (for sites that
On 09/14/2006 05:28 PM, Jim Jagielski wrote:
There is a lot of confusion where the users think that
simply adding the stickysession param to the http worker
attribute *adds* the required sticky session info (cookie).
I'm looking into adding functionality that actually
does that and
Hi,
I discovered this bug in a huge chunk of code that deals with huge
uploads and it took me *ages* to work out what was causing it. But once
I had, I whittled it down to a small testcase. Any upload whose size is
an exact multiple of 64K (which appears to be the block size used by the
On 09/14/2006 06:14 PM, Jim Jagielski wrote:
That's what I'm thinking, sort of like an 'autostickysession' attribute.
We could even have it default to cookies but add something like
'autostickysession=url' to force URL rewriting and adding a tag
to the end of the URL (for sites that
On 09/14/2006 09:50 PM, Ruediger Pluem wrote:
or even
Header add Set-Cookie MYCOOKIE=SOMEVALUE.%{BALANCER_WORKER_ROUTE}e; path=/;
env=BALANCER_ROUTE_CHANGED
ProxyPass /test balancer://mycluster/test stickysession=MYCOOKIE nofailover=On
Ok I think it should be
Header add Set-Cookie
Graham-
Thanks for the reply.
I have DirectoryIndex inherited from httpd.conf.
The handler is a PythonHandler.
Read the link you sent later -- I'm not clueful enough yet to know if that's
biting me (it seems to only apply to the earlier handlers, no?) -- but yes, we
are running 3.2.10.
On Sep 14, 2006, at 3:49 PM, Ruediger Pluem wrote:
On 09/14/2006 06:14 PM, Jim Jagielski wrote:
That's what I'm thinking, sort of like an 'autostickysession'
attribute.
We could even have it default to cookies but add something like
'autostickysession=url' to force URL rewriting and
Do you have the DirectoryIndex directive defined explicitly or inherited
from outer scope? What handler phase are you defining your mod_python
handler in?
Graham
Mike Glover wrote ..
I'm working on an OpenID access control using mod_python. As part of the
OpenID protocol, our code redirects
Still answer the questions, but you might also be getting impacted by:
http://issues.apache.org/jira/browse/MODPYTHON-140
This is fixed in mod_python 3.3, but not in 3.2.10.
Graham
Graham Dumpleton wrote ..
Do you have the DirectoryIndex directive defined explicitly or inherited
from outer
If you are using PythonHandler then and not an earlier phase, I don't
understand why your handler is being called in the first place then for
those files. Which means of creating a sub request is mod_autoindex
using? I was presuming that it would be using the means of doing a
sub request which
Hmmm, mod_autoindex also does:
if (ap_run_sub_req(rr) != OK) {
/* It didn't work */
emit_amble = suppress_amble;
emit_H1 = 1;
}
but why?
So it is forcing something through to the response handler phase,
Sorry for spamming the list with so many quick messages, I'll stop
now. One more question first though.
How are you causing the PythonHandler to be triggered? Are you
using SetHandler/AddHandler or some other configuration. It would
help perhaps if you post your actual Apache configuration
Graham-
Here's the snippet out of .htaccess that's calling the handler:
Files bar.html
PythonAccessHandler mpopenid::requireOpenIDAuth
PythonOption allowed-users mike.glover.myopenid.com
/Files
As you can see, I was wrong about it being a PythonHandler -- I was looking at
a
Mike Glover wrote ..
Graham-
Here's the snippet out of .htaccess that's calling the handler:
Files bar.html
PythonAccessHandler mpopenid::requireOpenIDAuth
PythonOption allowed-users mike.glover.myopenid.com
/Files
As you can see, I was wrong about it being a
48 matches
Mail list logo
