Make WordPress Core

Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#14062 closed defect (bug) (fixed)

some Location headers are using relative url's

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


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:

Location: http://www.w3.org/pub/WWW/People.html

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 9 years ago.
Use self_admin_url to ensure network admin compatibility.
14062.2.diff (5.6 KB) - added by PeteMall 9 years ago.
Use self_admin_url() in plugins.php.
14062.patch (1.2 KB) - added by ocean90 9 years ago.

Download all attachments as: .zip

Change History (23)

#1 @hakre
9 years ago

Related: #13909

#2 @dd32
9 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
9 years ago

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

#4 @voyagerfan5761
9 years ago

  • Cc WordPress@… added

#5 @hakre
9 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
9 years ago

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

#7 @dd32
9 years ago

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

#8 @dd32
9 years ago

  • Milestone changed from Awaiting Review to 3.1

#9 @dd32
9 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
9 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
9 years ago

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

#12 @dd32
9 years ago

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

9 years ago

Use self_admin_url to ensure network admin compatibility.

#13 @ryan
9 years ago

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

9 years ago

Use self_admin_url() in plugins.php.

#14 @ocean90
9 years ago

  • Keywords has-patch added; needs-patch removed

9 years ago

#16 @ocean90
9 years ago

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

#17 @nacin
9 years ago

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

#18 @nacin
9 years ago

Good for 3.1?

#19 @ryan
9 years ago

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

Let's call it done.

#20 @hakre
9 years ago

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

Note: See TracTickets for help on using tickets.