Une image fonctionne via une connexion directe rapide, mais arrive incomplète via un proxy de transfert plus lent. Une cause possible est que l'origine ferme la connexion alors que sa réponse est encore en cours d'écriture.

Les E/S de Netty sont asynchrones. Revenir de writeAndFlush ne signifie pas que l'opération est terminée. Cet ordre n'est donc pas sûr pour une réponse qui a encore des octets en file d'attente :

ctx.writeAndFlush(response);
ctx.close();

Lorsque l'échange HTTP se ferme intentionnellement après son dernier message de réponse, attachez la fermeture au future de cette écriture :

ctx.writeAndFlush(finalResponseMessage)
    .addListener(ChannelFutureListener.CLOSE);

L'extrait suppose que la réponse a déjà été correctement construite et tramée. Pour un corps diffusé en flux, utilisez la fin de son dernier message plutôt que l'écriture de ses en-têtes. Pour une connexion HTTP persistante, n'ajoutez pas de fermeture simplement parce qu'une réponse est terminée.

Examinez l'échec du future dans le cadre de la gestion normale des erreurs de l'application. La fin inclut l'échec et l'annulation ; la fin seule n'est donc pas un accusé de livraison du navigateur.

La comparaison utile est la longueur complète de la réponse et le résultat de l'écriture sur chaque chemin. Un proxy peut modifier suffisamment le timing pour révéler une erreur de cycle de vie existante ; sa présence ne prouve pas que son compresseur ou son cache a écarté les octets.

Articles similaires