I would like to propose two enhancements to mod_ftp.
The same way we have FTPJailUser and CreateHomeDir directives, we would
need
FTPJailGroup and CreateGroupDirs directives.
This would allow us manage FTP files based on groups, rather than single
individual users.
Thoughts? Anyone intereste
Helmut Tessarek wrote:
> On 30.03.2007 05:24, Tom Donovan wrote:
>> One problem with your patch is that it wouldn't distinguish between a
>> 32-character password (plain-text passwords work on Windows) and an md5
>> hash.
>
> This is correct, but plain text passwords are only supported on Windows
J. Daniel Rotenberg said:
> In this situation I would use something like
> ap_server_root_relative() and prepend the 'logs' part to whatever your
> cache file name is. I'm not positive that this guarantees that you get
> an existing directory, though.
>
> Your safest bet is to retain your directive
In this situation I would use something like
ap_server_root_relative() and prepend the 'logs' part to whatever your
cache file name is. I'm not positive that this guarantees that you get
an existing directory, though.
Your safest bet is to retain your directive but make it optional. Set
a default
In reference to my last question (about finding a suitable cache-file
directory), I found this function in the httpd-2.2.x source:
apr_temp_dir_get(char** temp_dir, apr_pool t* p).
Has anyone used this function or does anyone know if it is (or is not) fully
supported by all apache implementations
On 30.03.2007 05:24, Tom Donovan wrote:
> One problem with your patch is that it wouldn't distinguish between a
> 32-character password (plain-text passwords work on Windows) and an md5
> hash.
This is correct, but plain text passwords are only supported on Windows because
of the lack of the crypt
Hi
Plüm wrote:
I guess what Nick is talking about is the body of a redirect response.
A redirect response is often accompanied by a small HTML page that also
contains the redirect target as a hyperlink in the case that your client
does not understand the Location header. While ProxyPassReverse t
> -Ursprüngliche Nachricht-
> Von: Stuart Children
> Gesendet: Donnerstag, 5. April 2007 14:25
> An: dev@httpd.apache.org
> Betreff: Re: ProxyErrorOverride and redirects (PR 39245)
>
>
> > Looks to me like a valid usage case for ProxyErrorOverride 3xx.
>
> I don't see how it would ach
Nick Kew wrote:
A redirection page is likely to include a redirected URL.
In a reverse proxy situation, that may need to be rewritten.
Conceivably, yes. Though I would maintain that *by default* people with
reverse-proxies would want/expect all their headers retained intact.
Use of ProxyEr
Joe Orton wrote:
The original code did only override >= 400 responses, but was broken as
described in PR 20183. That was changed to override all >= 300
responses as what looks like a mis-guided attempt to fix PR 22951, which
was probably really just PR 20183 in disguise:
http://svn.apache.o
On Wed, Apr 04, 2007 at 10:34:31PM +0100, Stuart Children wrote:
> Behaviour *has already been broken* from 2.0.x to 2.2.x - I've given
> evidence of this. Our work systems heavily rely on the 2.0 behaviour.
> Maybe someone else would like to repeat my tests - it's possible
> it's not as simple
On Thu, 5 Apr 2007 10:04:19 +0100
Joe Orton <[EMAIL PROTECTED]> wrote:
> I agree that the intended behaviour of the original code was
> intuitively correct, only >= 400 errors should be overriden,
A redirection page is likely to include a redirected URL.
In a reverse proxy situation, that may ne
12 matches
Mail list logo
