Bug 59267

Created attachment 33722 [details]
Introduces new RewriteOptions parameter URLPathLocation for allowing URL-Path as redirect target (Location header) instead of fully-qualified URL

Introduces new RewriteOptions parameter URLPathLocation.

Sample usage:

RewriteEngine On
RewriteOptions URLPathLocation
RewriteRule ^/path\.html /longerpath.html [redirect=permanent,last]

This results in the following http response:

HTTP/1.1 301 Moved Permanently
Location: /longerpath.html
[...]

Without this patch, of with "RewriteOptions URLPathLocation" not set, the "Location:" header is converted to a fully-qualified URL:

HTTP/1.1 301 Moved Permanently
Location: http://hostname/longerpath.html
[...]

As since 2014 with RFC 7231 7.1.2. (https://tools.ietf.org/html/rfc7231#section-7.1.2) a URL-Path as Location: is sufficient, and all current browsers support this, Apache httpd should offer usage of this standard.

This enhancement originates from a requirement to combine a caching CDN, technially a reverse caching proxy, offering https and http for the same virtual host and using http only as backend connection. This reduced security setting is useful where no personal data is transferred but man-in-the-middle listeners near the client side should be prevented from accessing the data.

The specific CDN used in this case is caching redirect responses without adding the protocol of the original request as additional cache key. That means, once the URL http://hostname/path is requested by client A, which is redirected by the backend server to http://hostname/longerpath, a subsequent request by client B to the same URL-Path but using a different protocol to https://hostname/path is redirected to the cached response http://hostname/longerpath instead of https://hostname/longerpath.

This patch does not modify the default behavior if "RewriteOptions URLPathLocation" is not set. It only adds in this case 2 invocations of ap_get_module_config() per RewriteRule evaluation if the RewruteRule contains the flag "rewrite". If a RewriteRule contains a URL-Path as target, the previous behavior of mod_rewrite of converting it to a fully-qualified URL by prepending the protocol, hostname and port of the virtual host is not changed.

If "RewriteOptions URLPathLocation" is set, the given URL-Path in the RewriteRul is used directly. All other flags of RewriteRule are still evaluated, including "noescape".

Another httpd component using automatically created fully-qualified URL as redirect target is mod_dir. If a URL to a directory is requested while omitting the trailing slash, mod_dir redirects to the same URL-Path appended by a trailing slash if the default setting of DirectorySlash is used. As redirect target, the URL-Path is converted to a fully-qualified URL. If a URL-Path instead of a fully-qualified URL is required by the use-case described above, the following workaround is possible using mod_redirect:

RewriteEngine On
RewriteURLPathLocation On
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -d
RewriteRule .* /%1/ [redirect=permanent,last]

To allow URL-Paths on directory redirects with omitted trailing slash, without using this workaround, an additional patch, this time for mod_dir, is contributed, adding the new parameter DirectoryRedirectURLPath.

Other possible usages of hard-coded fully-qualified URLs as redirect location target:
mod_userdir.c
mod_speling.c
mod_imagemap.c
mod_alias.c
http_request.c
mod_cgi.c
mod_cgid.c

So instead of adding a special handling to mod_dir, a core option for enabling URL-Paths as location target might be preferable. Though for mod_rewrite, this patch should be seen independent of other possible changes, as mod_rewrite should offer generous flexbility.