Brian McCallister wrote:
> Finally finished up the import of mod_wombat into httpd svn (
> http://svn.apache.org/repos/asf/httpd/mod_wombat ).
>
> The code has been idle while going through the software grant process in
> the incubator. Now that it is here I am eager to start working on it again.
On Fri, 13 Apr 2007 16:30:06 -0500
Andy Wang <[EMAIL PROTECTED]> wrote:
> There are a number of potential workarounds (LocationMatch, or
> Multiple Location blocks to deal with the ;* pattern) but it does
> seem like this is a bug unless someone can clarify RFC 2396 section
> 3.3 for me and explai
I just submitted bug 42120. It appears that Apache is improperly (at
least I think it's improper) matching Location blocks when doing
authentication if a path component parameter is passed on.
Specifically, something like this
{Auth stuff}
In this scenario, if I hit http://server/webapp/se
Oh didn't catch that i was scanning through the documentation with
"cat" on a ssh session from a PDA when I wrote this.
I'll look into this since that might be of use for me already then.
On 4/13/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
You can do this today using FTPJailUser.
Tryin
David Wortham wrote:
> Sorry if this isn't the primary focus of this message-list, but I have a
> general question about APR and timestamps (more about apr_int64_t).
>
> The typedef of apr_time_t is apr_int64_t. I assume this type is 64 bits
> long on a 64 bit system. Is it 64 bits long on a 32b
Sorry if this isn't the primary focus of this message-list, but I have a
general question about APR and timestamps (more about apr_int64_t).
The typedef of apr_time_t is apr_int64_t. I assume this type is 64 bits
long on a 64 bit system. Is it 64 bits long on a 32bit (or smaller) system?
The "
Finally finished up the import of mod_wombat into httpd svn ( http://
svn.apache.org/repos/asf/httpd/mod_wombat ).
The code has been idle while going through the software grant process
in the incubator. Now that it is here I am eager to start working on
it again.
There are a couple design
I encountered an error building libapreq2.08
I posted it on the mp list when I thought it was perl related, but
the issue seems to be in the C code , so i'm reposting here.
I'm running osx 10.4.9
Error
perl -MTest::Harness -e 'runtests(@ARGV)' version.t cookie.t params.
Hi.
I have a module (mod_xml2) that exports several functions and another
one (mod_i18n) that uses them. So by now mod_xml2 has to be loaded
first. This is of course not desirable and I want to get rid of it. Are
there any other possibilities than to make all exported functions
optional?
Sincerel
On Apr 13, 2007, at 12:03 PM, Mladen Turk wrote:
Jim Jagielski wrote:
Not according to my tests. The simple server push still
buffers the data.
Hmmm a followup commit has:
URL: http://svn.apache.org/viewvc?view=rev&rev=504559
so that may be exactly the case...
Huh, looks like it works n
Jim Jagielski wrote:
Not according to my tests. The simple server push still
buffers the data.
Hmmm a followup commit has:
URL: http://svn.apache.org/viewvc?view=rev&rev=504559
so that may be exactly the case...
Huh, looks like it works now. Although I didn't test is with
mod_deflat
On Apr 13, 2007, at 11:34 AM, Jim Jagielski wrote:
On Apr 13, 2007, at 5:20 AM, Mladen Turk wrote:
Plüm wrote:
+1 I will try to check it once you have proposed it and give it
a quick vote.
I have another one that fixes this issues for non-chunked content.
I haven't tried yet, but IMHO it
On Apr 13, 2007, at 5:20 AM, Mladen Turk wrote:
Plüm wrote:
+1 I will try to check it once you have proposed it and give it
a quick vote.
I have another one that fixes this issues for non-chunked content.
I haven't tried yet, but IMHO it should already work for non-chunked
content. Is this n
On Wed, 11 Apr 2007, Niklas Edmundsson wrote:
Looking a bit further, I think that something like this would actually be
enough:
I have now tested this patch, and it seems to solve the problem. This
is on httpd-2.2.4 + patch for PR41475 + our mod_disk_cache patches.
Without the patch a HEAD
On Apr 13, 2007, at 5:20 AM, Mladen Turk wrote:
Anyhow, I'll commit a patch to the trunk for http, cause its
configurable by flushwait and skipped otherwise.
Looking forward to seeing it... recall that if we flush at
every "chunk" with HTTP, we will be dead slow and filters
will not be happ
Hi,
looks like same patch works with the trunk out of the box.
However, attaching same patch against the trunk branch.
Short instructions to test it:
1. Apply the patch.
2. Compile httpd with mod_proxy and mox_rewrite enabled.
3. Add the following lines to httpd.conf:
ProxyRequests On
Rewrite
Plüm wrote:
+1 I will try to check it once you have proposed it and give it
a quick vote.
I have another one that fixes this issues for non-chunked content.
I haven't tried yet, but IMHO it should already work for non-chunked
content. Is this not the case?
Not according to my tests. The
> -Ursprüngliche Nachricht-
> Von: Mladen Turk
> Gesendet: Freitag, 13. April 2007 07:07
> An: [EMAIL PROTECTED]
> Betreff: Re: mod_proxy buffering small chunks
>
>
> Jim Jagielski wrote:
> >
> >>
> >> This is only fixed in trunk so far. See
> >> http://issues.apache.org/bugzilla/show
You can do this today using FTPJailUser.
Trying to take this one step deeper into the vhost concept and vhost
specific permissions, though.
Jorge Schrauwen wrote:
> Alternatively a different auth module could read and extra field that
> point the user to a different root directory.
>
> sjorge ==
Alternatively a different auth module could read and extra field that
point the user to a different root directory.
sjorge ==> /server/host/www.blackdot.be
wrowe ==> /server/host/apache.org
...
this way the user name would be free of @'s :)
Downside would be:
1. multiple domains can't have the
20 matches
Mail list logo
