Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

Related to this ticket about issues with inflating data.

So far it had been suggested by API's support to request gzip instead of deflate.

However I cannot find a way to override WP settings that set deflate with highest priority as accepted encoding for all requests.

Related functions - WP_Http_Encoding::is_available() and WP_Http_Encoding::accept_encoding().

Is there any hook or other option to control this that I am missing?

share|improve this question
    
I removed my previous answer because it was not a positive resolution to your question (and rather an answer saying that I can find no simple answer). Additionally, upon second look of previous answer, it was too short/thin with context and examples. –  Jonnybojangles Feb 25 '12 at 17:51
    
I have tired to look into the question ("Is there any hook or other option to control this that I am missing?") again and see no direct means to hook or filter WordPress' WP_Http_Encoding class (where the methods is_available, accept_encoding, and decompress are found). There are a few hooks and filters with in WP_http but none that I can see effecting deflate. Unfortunately, I can see no means to change WordPress' deflate priority outside of making edits and submitting patches to the core. Can you provide code examples of the request made by WordPress that needs a deflate method to be set? –  Jonnybojangles Feb 25 '12 at 17:53
    
@Jonnybojangles see links in question for use case... This is probably quite the edge case, but lack of control over this sucks big way when you do need to change it. –  Rarst Feb 25 '12 at 20:51
add comment

2 Answers 2

up vote 4 down vote accepted

Quite an edge case, but the accepted encoding types should be filterable nonetheless. I can see a few situations where fine, granular control over this header would be useful (as in adding an API that uses non-standard encoding).

So, while there's no stock hook for this, I have created a Trac ticket for it and submitted a patch. If you voice support on the ticket, maybe we can raise enough noise to get it incorporated into a future release.

share|improve this answer
1  
Thank you for raising issue there, as you know I don't do trac much. :) –  Rarst Feb 29 '12 at 17:38
add comment

Short answer: No, there's no hook for that.

Long answer: You could possibly submit a patch at WordPress Trac, if you really need to adjust this option. Personally, I didn't ever had problemes with WP_Http_Encoding::accept_encoding() and the question you mentioned could be answered by manually gzinflate() the response. IMHO, this seems to be the only solution until someone submits a patch.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.