Make WordPress Core

Opened 14 years ago

Closed 13 years ago

Last modified 13 years ago

#14062 closed defect (bug) (fixed)

some Location headers are using relative url's

Reported by: hakre's profile hakre Owned by: dd32's profile dd32
Milestone: 3.1 Priority: normal
Severity: normal Version: 3.0
Component: Administration Keywords: has-patch
Focuses: Cc:


While being on my HTTP related work lately I came over another issue. Many Redirects are violating the HTTP RFC in a way that the Location header is not containing an absolute URI as of which is to be used:

The Location response-header field is used to redirect the recipient
to a location other than the Request-URI for completion of the
request or identification of a new resource. For 201 (Created)
responses, the Location is that of the new resource which was created
by the request. For 3xx responses, the location SHOULD indicate the
server's preferred URI for automatic redirection to the resource. The
field value consists of a single absolute URI.

Location = "Location" ":" absoluteURI

An example is:


14.30 Location/RFC 2616; HTTP/1.1; June 1999

When I analyze the output, I get the following location header line:

Location: plugins.php?deactivate=true&plugin_status=active&paged=1

This is a relative URI, not a absolute one.

Attachments (3)

14062.diff (1.2 KB) - added by PeteMall 14 years ago.
Use self_admin_url to ensure network admin compatibility.
14062.2.diff (5.6 KB) - added by PeteMall 14 years ago.
Use self_admin_url() in plugins.php.
14062.patch (1.2 KB) - added by ocean90 13 years ago.

Download all attachments as: .zip

Change History (23)

#1 @hakre
14 years ago

Related: #13909

#2 @dd32
14 years ago

  • Component changed from HTTP to Administration
  • Owner set to dd32
  • Status changed from new to accepted
  • Summary changed from plugins.php violates Location Header HTTP 1.1 Specification to some Location headers are using relative url's

#3 @miqrogroove
14 years ago

+1. I've seen invalid Location headers cause problems, especially for robots.

#4 @voyagerfan5761
14 years ago

  • Cc WordPress@… added

#5 @hakre
14 years ago

One way would be to check each call of wp_redirect(). Another idea I have is to integreate a warning inside my better redirects plugin that does throw warnings if WP_DEBUG is enabled. Can help with plugin development as well.

#6 @dd32
14 years ago

Cross reference to a problem caused by this: #14904 (Install page not redirecting to wp-admin/ on IIS6)

#7 @dd32
14 years ago

(In [15680]) utilise wp_guess_url() in installation redirection to provide an Absolute URL. See #14062. See #14904

#8 @dd32
14 years ago

  • Milestone changed from Awaiting Review to 3.1

#9 @dd32
14 years ago

I'm considering what we should accept for wp_redirect();

Right now, I'm thinking that the addition of a wp_admin_redirect() which wraps the url with admin_url() before passing into wp_redirect() would be useful.

The other possibility is something such as this in wp_redirect:

if ( ! is a absolute url starting with a scheme ) {
   $url = is_admin() ? admin_url($url) : site_url($url);

That will catch more faulty redirects - but may break some plugins. In core it's mainly admin redirects which do not specify a full url, and wp-login.php.

#10 @jane
14 years ago

  • Keywords needs-patch added

If someone wants to do something about this for 3.1, it needs a patch to be posted now, or be punted to 3.2, as we are coming up on freeze.

#11 @dd32
14 years ago

(In [16006]) Use Absolute URL's in header redirects in wp-admin/plugin.php. See #14062

#12 @dd32
14 years ago

(In [16008]) Use Absolute URL's & API's in header redirects in more locations. See #14062

14 years ago

Use self_admin_url to ensure network admin compatibility.

#13 @ryan
14 years ago

(In [16015]) Use self_admin_url(). Props PeteMall. see #14062

14 years ago

Use self_admin_url() in plugins.php.

#14 @ocean90
13 years ago

  • Keywords has-patch added; needs-patch removed

13 years ago

#16 @ocean90
13 years ago

Use self_admin_url() in class-wp-plugin-install-list-table.php.

#17 @nacin
13 years ago

[16499] missed the ticket. I meant "see" not "fixes". Leaving this open.

#18 @nacin
13 years ago

Good for 3.1?

#19 @ryan
13 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

Let's call it done.

#20 @hakre
13 years ago

Follow-Up Ticket (some were left): #16909

Note: See TracTickets for help on using tickets.