Make WordPress Core

Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#20142 closed enhancement (fixed)

Allow WP_Http to filter Accept-Encoding Header

Reported by: ericmann's profile ericmann Owned by: dd32's profile dd32
Milestone: 3.6 Priority: normal
Severity: minor Version: 3.4
Component: HTTP API Keywords: has-patch
Focuses: Cc:


The WP_Http API supports sending the Accept-Encoding header, but doesn't allow developers to filter its value. This can be problematic when trying to create a request with a specific encoding.

For related discussion, see:

Attachments (1)

20142.diff (398 bytes) - added by ericmann 12 years ago.
Add wp_http_accept_encoding filter.

Download all attachments as: .zip

Change History (9)

12 years ago

Add wp_http_accept_encoding filter.

#1 @ericmann
12 years ago

  • Summary changed from Allow WP_Http to Allow WP_Http to filter Accept-Encoding Header

#2 follow-up: @dd32
12 years ago

The (oldish) Question asked in the linked ticket, and the Mailchimp question should be fixed in WordPress 3.3, The compression method that Mailchimp uses was added to the logic used to decompress the strings.

Long story short: Every compressor/decompressor is written different, some include the compression headers, some don't, some add extra characters, some don't, core seems to handle every case I've found documented online so far.. until someone comes out with yet-another-compression-method-thats-incompatible.

see [18718] and [18806]

#3 in reply to: ↑ 2 @ericmann
12 years ago

Replying to dd32:

Fair enough. I implemented this as a filter in the event that integration with some other system required shifting the order of types or if someone wanted to add/remove a custom type from the header.

That's why I marked it as minor as well. This isn't a bug, and isn't likely to break anything. Just adds a filter where one could be necessary in the future.

If you see it as completely unnecessary, feel free to close as "wontfix." I just figured it was an easy enough add for an array that, arguably, should've been filterable in the first place.

#4 @dd32
12 years ago

It's not a problem, I just knew I'd already fixed the cause of the request, so thought it best to mention it :)

I'm thinking that it should be allowed to be set via the headers array thats sent to WP_HTTP rather than a filter on the return value myself, that way it's per-request, rather than global, but i'm open to others opinions on that.

#5 @toscho
12 years ago

  • Cc info@… added

#6 @dd32
11 years ago

  • Milestone changed from Awaiting Review to 3.6

Lets get this fixed in 3.6

#7 @dd32
11 years ago

  • Owner set to dd32
  • Resolution set to fixed
  • Status changed from new to closed

In 23600:

WP_HTTP: Allow developers to specify a Accept-Encoding header. Fixes #20142

#8 @dd32
11 years ago

See also [23601] and #22913 for a filter on the default Accept-Encoding.

Note: See TracTickets for help on using tickets.