The DAV PUT method returns the location of the newly created resource in the Location: header of the response (RFC2616 14.30; RFC4918 13.1). However, Apache does not quote the contents of the newly created path segments when constructing the new Location: URL (RFC3986 2.4). This means that the response can be incorrect if the underlying resource name contains octet-sequences that are significant in URLs (such as "#" or "?") or in the HTTP protocol (such as CRLF) or both (whitespace, etc). Here's an example of a request and response using httpd 2.4.3 on an OS X machine (httpd 2.2.x has the same behavior): Request: PUT /pdav/test%23file HTTP/1.1 Content-Length: 8 Host: localhost Hello! Response: HTTP/1.1 201 Created Date: Wed, 02 Jan 2013 22:40:00 GMT Server: Apache/2.4.3 (Unix) OpenSSL/1.0.0j Location: http://localhost/pdav/test#file Content-Length: 71 Content-Type: text/html; charset=ISO-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>Connection closed by foreign host. The file is correctly created in the filesystem as "test#file", but the Location: header in the response is incorrect. PUTting to a URL such as ".../davcoll/foo%0A%0DBar:%20blahblah" may be a way to perform a response splitting attack (a la http://jeremiahgrossman.blogspot.com/2007/07/http-response-splitting-revelations.html ).
See also <https://issues.apache.org/bugzilla/show_bug.cgi?id=54611>, which seems like a more general case of Location headers not doing proper URI encoding.
In trunk/2.5 r1470683, Apache simply doesn't return a Location: header for PUTs any more (sigh), but the problem still happens for eg MKCOL. % curl -ik -X MKCOL 'http://localhost:9080/wiml/foo%0D%0Aoo' HTTP/1.1 201 Created Date: Tue, 23 Apr 2013 00:48:10 GMT Server: Apache/2.5.0-dev (Unix) OpenSSL/1.0.1c Location: http://localhost:9080/wiml/foo oo Content-Length: 71 Content-Type: text/html; charset=ISO-8859-1
Can you verify whether the patch applied from 54611 fixes this?
Yes 54611 resolved this.
The problem still exists under Debian 8 (Apache 2.4.10-8). So I think 54611 fix was not fixing this one
(In reply to Juergen Mertens from comment #5) I just ran the 'curl' test above against a bunch of recent httpd releases and it appears to be fixed in 2.4.6 and later (working: 2.4.6, 2.4.7, 2.4.9, 2.4.10, 2.4.12, 2.4.13-dev (r1665231), and 2.5.0-dev (r1665385); not working: 2.4.2, 2.4.4); methods MKCOL and PUT; on OSX 10.9.5. (I did notice that the bug you can see in my earlier report where the response is truncated after the "<title>" is also fixed as of 2.4.12!) Can you give more information on what request you're sending and what you're receiving back from the server?