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://server/GOLF/</D:href>. 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

<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--