Comment contrôler l'acceptation du codage sur les demandes d'API HTTP?

11

Lié à ce ticket sur les problèmes de gonflage des données .

Jusqu'à présent, le support de l'API avait suggéré de demander gzip au lieu de déflate .

Cependant, je ne trouve pas le moyen de remplacer les paramètres WP définissant le paramètre deflate avec la priorité la plus élevée comme codage accepté pour toutes les demandes.

Fonctions connexes - WP_Http_Encoding::is_available() et WP_Http_Encoding::accept_encoding() .

Existe-t-il un crochet ou une autre option pour contrôler cela qui me manque?

    
posée Rarst 01.08.2011 - 19:29

2 réponses

4

C’est un cas très complexe, mais les types de codage acceptés doivent néanmoins être filtrés. Je peux voir quelques situations où un contrôle fin et granulaire de cet en-tête serait utile (comme pour l'ajout d'une API utilisant un codage non standard).

Ainsi, bien qu’il n’y ait pas d’accrochage boursier, j’ai créé un ticket Trac pour celui-ci et envoyé un correctif . Si vous exprimez votre soutien sur le ticket, nous pourrons peut-être générer suffisamment de bruit pour l’intégrer à une version ultérieure.

    
réponse donnée EAMann 29.02.2012 - 17:51
2

Réponse courte: Non, il n'y a pas de crochet pour cela.

Réponse longue: vous pouvez éventuellement envoyer un correctif sur WordPress Trac , si vous devez vraiment ajuster cette option. Personnellement, je n'ai jamais eu de problèmes avec WP_Http_Encoding::accept_encoding() et la question mentionné pourrait recevoir une réponse manuellement gzinflate() la réponse. IMHO, cela semble être la seule solution jusqu'à ce que quelqu'un soumette un correctif.

    
réponse donnée swissspidy 28.02.2012 - 21:56

Lire d'autres questions sur les étiquettes