httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 59267] New: Allow URL-Path as redirect target (Location header) instead of fully-qualified URL
Date Sun, 03 Apr 2016 22:24:00 GMT

            Bug ID: 59267
           Summary: Allow URL-Path as redirect target (Location header)
                    instead of fully-qualified URL
           Product: Apache httpd-2
           Version: 2.4.10
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: mod_rewrite

Created attachment 33722
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.
( 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
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

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.

You are receiving this mail because:
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message