WordPress.org

Make WordPress Core

#24663 closed defect (bug) (fixed)

esc_url_raw() strips out square brackets in URLs

Reported by: thomaswm Owned by: nacin
Milestone: 3.6 Priority: high
Severity: major Version: 3.5.2
Component: HTTP API Keywords:
Focuses: Cc:

Description

Hi,

if you try to request a URL through wp_remote_fopen(), since WP v 3.5.2, it is validated by wp_http_validate_url() which passes it on to esc_url_raw().

We use the ICS Calendar plugin on our blog. It tries to request URLs of the form

http://$domain/events/ical?gid[]=34

via wp_remote_fopen() but esc_url_raw() strips out the square brackets. So WP requests

http://$domain/events/ical?gid=34


instead. I have verified that this problem is caused by esc_url_raw() by uncommenting the line

$url = esc_url_raw( $url, array( 'http', 'https' ) );

in wp-includes/http.php

Greets,
Thomas

Attachments (1)

24663.diff (443 bytes) - added by nacin 10 months ago.

Download all attachments as: .zip

Change History (10)

comment:1 SergeyBiryukov10 months ago

Related/duplicate: #16859

comment:2 follow-up: ocean9010 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

esc_url_raw() is just a wrapper for esc_url() with context = db. So a duplicate of #16859.

comment:3 in reply to: ↑ 2 SergeyBiryukov10 months ago

Replying to ocean90:

esc_url_raw() is just a wrapper for esc_url() with context = db. So a duplicate of #16859.

Correct. I just thought I'd keep it open to see if this should be considered in light of the changes in 3.5.2 ([24481]).

comment:4 nacin10 months ago

  • Milestone set to 3.6
  • Priority changed from normal to high
  • Resolution duplicate deleted
  • Severity changed from normal to major
  • Status changed from closed to reopened

I'm going to re-open this temporarily, to see if we should be solving this a different way. I wonder if we should actually avoid esc_url_raw() all together here and let wp_kses_bad_protocol() do the work. dd32?

comment:5 dd3210 months ago

I wonder if we should actually avoid esc_url_raw() all together here and let wp_kses_bad_protocol() do the work. dd32?

If wp_kses_bad_protocols() covers all of our bases here, then esc_url_raw() would be unneeded obviously. It seems that we can probably get away with not applying the strict URL-contains-bad-entities code which esc_url_raw() has so it seems like a safe bet.

nacin10 months ago

comment:6 nacin10 months ago

Let's get duck_ to look at 24663.diff.

comment:7 follow-up: duck_10 months ago

Looks like a good idea.

Should the validation function check that there is a host component after parsing the URL?

comment:8 in reply to: ↑ 7 nacin10 months ago

Replying to duck_:

Should the validation function check that there is a host component after parsing the URL?

Yeah.

comment:9 nacin10 months ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from reopened to closed

In 24641:

In wp_http_validate_url(), only validate the protocol in lieu of esc_url_raw(). Ensure there is a host component to the URL. fixes #24663.

Note: See TracTickets for help on using tickets.