Return-Path:
X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io
Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io
Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183])
by cust-asf2.ponee.io (Postfix) with ESMTP id A76FC200C32
for ; Thu, 9 Mar 2017 09:17:40 +0100 (CET)
Received: by cust-asf.ponee.io (Postfix)
id A6175160B67; Thu, 9 Mar 2017 08:17:40 +0000 (UTC)
Delivered-To: archive-asf-public@cust-asf.ponee.io
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by cust-asf.ponee.io (Postfix) with SMTP id C84C5160B64
for ; Thu, 9 Mar 2017 09:17:39 +0100 (CET)
Received: (qmail 40788 invoked by uid 500); 9 Mar 2017 08:17:38 -0000
Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
list-help:
list-unsubscribe:
List-Post:
List-Id:
Delivered-To: mailing list users@httpd.apache.org
Received: (qmail 40777 invoked by uid 99); 9 Mar 2017 08:17:38 -0000
Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Mar 2017 08:17:38 +0000
Received: from localhost (localhost [127.0.0.1])
by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id D3598C1404
for ; Thu, 9 Mar 2017 08:17:37 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org
X-Spam-Flag: NO
X-Spam-Score: 2
X-Spam-Level: **
X-Spam-Status: No, score=2 tagged_above=-999 required=6.31
tests=[HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001,
URIBL_BLOCKED=0.001] autolearn=disabled
Received: from mx1-lw-us.apache.org ([10.40.0.8])
by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024)
with ESMTP id x22bCZahpWqW for ;
Thu, 9 Mar 2017 08:17:36 +0000 (UTC)
Received: from mail.schaubroeck.be (mail.schaubroeck.be [193.75.212.6])
by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id A69425F1EE
for ; Thu, 9 Mar 2017 08:17:35 +0000 (UTC)
Received: from proxy.schaubroeck.mailrelay ([192.168.1.4])
by mail.schaubroeck.be (8.14.3/8.14.3/ESMTP) with ESMTP id v298HQrX028847
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
for ; Thu, 9 Mar 2017 09:17:27 +0100
Received: from [192.168.226.35] ([192.168.226.35])
by proxy.schaubroeck.mailrelay (8.14.3/8.14.3/ESMTP) with ESMTP id v298HRgk011040
for ; Thu, 9 Mar 2017 09:17:27 +0100
Reply-To: jeremy.maes@cipalschaubroeck.be
To: users@httpd.apache.org
From: Jeremy Maes
Organization: Cipal Schaubroeck NV
Message-ID: <9ed5037f-83ed-5660-f226-a2d53ebfae4b@cipalschaubroeck.be>
Date: Thu, 9 Mar 2017 09:17:26 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="------------DE694EA35B207A8E194F74F4"
X-Virus-Scan: maila: scanned with KAV
X-SMTP-From:
X-Spam-Result: No (<0.5)
Subject: [users@httpd] Mod_dav configuration question
archived-at: Thu, 09 Mar 2017 08:17:40 -0000
--------------DE694EA35B207A8E194F74F4
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi
Since a few months we're using WebDAV (apache mod_dav) to serve files
for one of our apps. Everything works alright but when combined with an
older WebDAV client (needed for Office 2010 and older) we're running
into some issues.
The company that made the client has looked into the problem and gives
this as a possible cause for our issues:
> You WebDAV server returns path without domain in href. For example /GOLF/ instead of http://server/GOLF/. This may not work with some mini-redirector
> versions, especially with older Windows versions.
When we check the traffic with Fiddler it seems mod_dav is indeed
returning relative paths instead of the full path. I've searched the
documentation for an option that might force the use of full paths but
couldn't find one. Does anybody have an idea if such an option exists or
how I'd be able to force this behavior?
We're running on RHEL6 (apache 2.2.15), using mod_dav. Specific webdav
config file:
> Listen 44595
>
>
> DocumentRoot /shares/webdav
>
>
> LimitXMLRequestBody 131072
>
>
> Order Allow,Deny
> Allow from all
>
> Dav On
> Options -Indexes
> AllowOverride None
> AddDefaultCharset UTF-8
>
>
>
Thanks in advance for any insights.
--
Kind regards,
Jeremy
**** DISCLAIMER ****
http://www.cipalschaubroeck.be/disclaimer
--------------DE694EA35B207A8E194F74F4
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
Hi
Since a few months we're using WebDAV (apache mod_dav) to serve
files for one of our apps. Everything works alright but when
combined with an older WebDAV client (needed for Office 2010 and
older) we're running into some issues.
The company that made the client has looked into the problem and
gives this as a possible cause for our issues:
You WebDAV server returns path without domain in href. For example <D:href>/GOLF/</D:href> instead of <D:href>http:
When we check the traffic with Fiddler it seems mod_dav is indeed
returning relative paths instead of the full path. I've searched
the documentation for an option that might force the use of full
paths but couldn't find one. Does anybody have an idea if such an
option exists or how I'd be able to force this behavior?
We're running on RHEL6 (apache 2.2.15), using mod_dav. Specific
webdav config file:
Listen 44595
<VirtualHost *:44595>
DocumentRoot /shares/webdav
<IfModule mod_dav.c>
LimitXMLRequestBody 131072
<Directory /shares/webdav/>
Order Allow,Deny
Allow from all
Dav On
Options -Indexes
AllowOverride None
AddDefaultCharset UTF-8
</Directory>
</IfModule>
</VirtualHost>
Thanks in advance for any insights.
--
Kind regards,
Jeremy
**** DISCLAIMER ****
http://www.cipalschaubroeck.be/disclaimer
--------------DE694EA35B207A8E194F74F4--