WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 14 months ago

Last modified 14 months ago

#20142 closed enhancement (fixed)

Allow WP_Http to filter Accept-Encoding Header

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

Description

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 2 years ago.
Add wp_http_accept_encoding filter.

Download all attachments as: .zip

Change History (9)

ericmann2 years ago

Add wp_http_accept_encoding filter.

comment:1 ericmann2 years ago

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

comment:2 follow-up: dd322 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]

comment:3 in reply to: ↑ 2 ericmann2 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.

comment:4 dd322 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.

comment:5 toscho18 months ago

  • Cc info@… added

comment:6 dd3214 months ago

  • Milestone changed from Awaiting Review to 3.6

Lets get this fixed in 3.6

comment:7 dd3214 months 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

comment:8 dd3214 months ago

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

Note: See TracTickets for help on using tickets.