Encodage du contenu

Comme spécifié dans le protocole HTTP (RFC 2616), les applications peuvent demander au serveur de retourner des réponses HTTP au format codé. Avant Windows Server 2008 et Windows Vista, les demandes avec encodage de contenu étaient envoyées à l’application pour traitement à leur niveau. À compter de Windows Server 2008 et Windows Vista, l’application peut demander à WinINet d’effectuer le décodage du contenu pour les schémas d’encodage de contenu gzip et de déflate.

Pour activer le décodage de contenu, l’application définit l’option de décodage demandant à WinINet d’effectuer le décodage en leur nom. Toutefois, l’activation du décodage ne garantit pas que WinINet effectuera le décodage du contenu, et l’application doit être prête à gérer le décodage. WinINet supprime l’en-tête d’encodage de contenu de la réponse lorsque le décodage de contenu est effectué avec succès. Les applications sont censées gérer le décodage du contenu, que l’option de décodage soit activée ou désactivée lorsque l’en-tête d’encodage de contenu est présent dans la réponse.

Lorsque le décodage est activé, l’application doit spécifier la liste des encodages pris en charge dans l’en-tête Accept-Encoding de la requête. Toutefois, l’en-tête Accept-Encoding n’oblige pas le serveur à envoyer une réponse encodée. WinINet envoie à l’application des réponses qui ne correspondent pas à la liste des encodages acceptables.

La liste suivante décrit les conditions dans lesquelles WinINet effectue le décodage de contenu lorsque l’option est activée :

• L’en-tête Accept-Encoding doit être présent dans la demande et doit spécifier les schémas d’encodage gzip, deflate ou gzip et deflate.
• Le schéma d’encodage spécifié dans l’en-tête Content-Encoding doit correspondre à l’un des schémas d’encodage spécifiés dans l’en-tête Accept-Encoding.
• L’en-tête Content-Encoding dans la réponse spécifie un seul schéma d’encodage.
• La réponse ne doit contenir qu’un seul en-tête Content- Encoding. WinINet décode le contenu encodé avec un seul schéma d’encodage.
• L’en-tête Cache-Control ne doit pas contenir la directive sans transformation.
• L’en-tête Content-Range ne doit pas être présent dans la réponse.

Définition de l’option Décompression

L’option de décodage peut être définie sur le handle de session, le handle de requête ou le handle de connexion. Le handle sur lequel l’option de décodage est définie, définit l’étendue de l’option de décodage. Par exemple, la définition du décodage sur la session permet de décoder toutes les connexions et demandes créées sous ce handle.

Pour définir l’option de décodage, l’application appelle InternetSetOption avec le handle retourné par InternetOpen, InternetConnect ou HttpOpenRequest. L’option INTERNET_OPTION_HTTP_DECODING est spécifiée dans le paramètre dwOption, et le paramètre lpBuffer pointe vers une variable booléenne définie sur true. Pour désactiver le décodage, l’application appelle InternetSetOption avec l’option INTERNET_OPTION_HTTP_DECODING et la variable booléenne définie sur false.

Lorsque l’option de décodage est définie, WinINet effectue le décodage sur la demande lorsque l’application appelle InternetReadFile. Si WinINet rencontre une erreur lors du décodage du contenu, l’appel à InternetReadFile échoue avec un ERROR_INTERNET_DECODING_FAILED. En cas d’échec du décodage, l’application dispose de deux options : elle peut supprimer l’en-tête Accept-Encoding et renvoyer la demande, ou elle peut définir l’option INTERNET_OPTION_HTTP_DECODING sur la demande sur false, puis renvoyer la demande. Si l’option de décodage est définie sur false, l’application doit case activée l’en-tête Content-Encoding et effectuer tout décodage au niveau de l’application.

Notes

WinINet ne prend pas en charge les implémentations de serveur. En outre, il ne doit pas être utilisé à partir d’un service. Pour les implémentations de serveur ou les services, utilisez Microsoft Windows HTTP Services (WinHTTP).