On Sunday 31 January 2010, Justin Erenkrantz wrote:
On Sun, Jan 31, 2010 at 3:01 AM, Stefan Fritsch s...@sfritsch.de
wrote:
On Sat, 30 Jan 2010, Justin Erenkrantz wrote:
I don't see how your patch would intentionally break - the
failure mechanism is that the source scripts are served - not
On Sat, 30 Jan 2010, Justin Erenkrantz wrote:
I don't see how your patch would intentionally break - the failure
mechanism is that the source scripts are served - not that a
configuration error stops the server from running. -- justin
Surely a fatal server error is not a necessary condition
On Sun, Jan 31, 2010 at 3:01 AM, Stefan Fritsch s...@sfritsch.de wrote:
On Sat, 30 Jan 2010, Justin Erenkrantz wrote:
I don't see how your patch would intentionally break - the failure
mechanism is that the source scripts are served - not that a
configuration error stops the server from
On Saturday 30 January 2010, Roy T. Fielding wrote:
*/
if (!conf-provider-repos-handle_get) {
+if (r-finfo.filetype != APR_DIR)
+r-handler = none;
return DECLINED;
}
}
It looks to me like that would introduce a
On 30 Jan 2010, at 12:04 PM, Stefan Fritsch wrote:
The recommended setup is to map separate URLs for DAV and script
execution to the content. It has been like this since at least 2.0.
The patch intentionally breaks existing configs that rely on the
ability to use the same URLs for DAV and
On Sat, 30 Jan 2010, Graham Leggett wrote:
On 30 Jan 2010, at 12:04 PM, Stefan Fritsch wrote:
I don't follow how this makes it easier to use the recommended setup?
In your example config, you defined /dav as being handled by mod_dav, and
then you defined a FilesMatch (as I recall) that
Stefan Fritsch wrote:
Hi,
mod_dav doesn't handle GET requests in a consistent way: If a repos
provider has handle_get == 1, mod_dav will handle GET requests by
itself. This means no other handler will get a chance to interpret the
file as script or SSI. On the other hand, if the repos
-Original Message-
From: Stefan Fritsch
Sent: Freitag, 29. Januar 2010 08:43
To: dev@httpd.apache.org
Subject: mod_dav inconsistent behaviour for GET requests
Hi,
mod_dav doesn't handle GET requests in a consistent way: If a repos
provider has handle_get == 1, mod_dav
It seems my mail was not so clear.
On Friday 29 January 2010, Plüm, Rüdiger, VF-Group wrote:
The documentation
http://httpd.apache.org/docs/trunk/mod/mod_dav.html#complex
suggests using ForceType 'text/plain' to circumvent this. Apart
from the fact that this is not enough and one may
On Friday 29 January 2010, Julian Reschke wrote:
And if you really really have to, consider using the MS extension
request header Translate.
Not all DAV clients send this header. Therefore it is not an option.
-Original Message-
From: Stefan Fritsch
Sent: Freitag, 29. Januar 2010 11:26
To: dev@httpd.apache.org
Subject: Re: mod_dav inconsistent behaviour for GET requests
It seems my mail was not so clear.
On Friday 29 January 2010, Plüm, Rüdiger, VF-Group wrote
On Friday 29 January 2010, Plüm, Rüdiger, VF-Group wrote:
Thanks for clarification. I guess I understand your intension
better now. So basicly you want those providers that do not
implement GET by themselves to enforce the usage of the default
handler, correct?
Mind to sent a patch to the
On Jan 29, 2010, at 10:46 AM, Stefan Fritsch wrote:
On Friday 29 January 2010, Plüm, Rüdiger, VF-Group wrote:
Thanks for clarification. I guess I understand your intension
better now. So basicly you want those providers that do not
implement GET by themselves to enforce the usage of the
Hi,
mod_dav doesn't handle GET requests in a consistent way: If a repos
provider has handle_get == 1, mod_dav will handle GET requests by
itself. This means no other handler will get a chance to interpret the
file as script or SSI. On the other hand, if the repos provider has
handle_get == 0,
14 matches
Mail list logo
