Voilà, depuis la nouvelle version du site, les utilisateurs sous Google Chrome ont beaucoup de mal à poster des commentaires. En réalité, cela fonctionne, le commentaire est bien publié, mais l’AJAX n’ayant pas un retour positif, il donne l’impression à l’utilisateur que le message n’a pas été envoyé – alors qu’il l’a été.

C’est dommage car Google Chrome représente plus de 50% des visiteurs : C’est donc un bug majeur.

Quel est la cause du problème

Ayant fait un peu le tour du web, je comprends que c’est lié au « chunked » et à un « Content-Length » incorrect. Google Chrome vérifie que les données concorde et si ce n’est pas le cas… Il s’arrête. Le soucis, c’est que mes données sont envoyées en GZip (compressée) donc forcément, impossible pour le serveur de savoir combien fera le fichier AVANT de le Gzipper (puisque le fichier contenant ce fameux Content-Length est DANS ce fichier Gzip).

Que faire ?

Personnellement, je me dis que désactiver Gzip et Deflate devraient résoudre le problème, mais je n’ai pas encore réussi à le faire (il faut dire que le fichier de configuration est vraiment complexe).  D’ailleurs, on peut voir dans le code source de Chromium la façon dont Chrome renvoi cette erreur :

int HttpStreamParser::DoReadBodyComplete(int result) {
// When the connection is closed, there are numerous ways to interpret it.
//
// – If a Content-Length header is present and the body contains exactly that
// number of bytes at connection close, the response is successful.
//
// – If a Content-Length header is present and the body contains fewer bytes
// than promised by the header at connection close, it may indicate that
// the connection was closed prematurely, or it may indicate that the
// server sent an invalid Content-Length header. Unfortunately, the invalid
// Content-Length header case does occur in practice and other browsers are
// tolerant of it. We choose to treat it as an error for now, but the
// download system treats it as a non-error, and URLRequestHttpJob also
// treats it as OK if the Content-Length is the post-decoded body content
// length.
//
// – If chunked encoding is used and the terminating chunk has been processed
// when the connection is closed, the response is successful.
//
// – If chunked encoding is used and the terminating chunk has not been
// processed when the connection is closed, it may indicate that the
// connection was closed prematurely or it may indicate that the server
// sent an invalid chunked encoding. We choose to treat it as
// an invalid chunked encoding.
//
// – If a Content-Length is not present and chunked encoding is not used,
// connection close is the only way to signal that the response is
// complete. Unfortunately, this also means that there is no way to detect
// early close of a connection. No error is returned.
if (result == 0 && !IsResponseBodyComplete() && CanFindEndOfResponse()) {
if (chunked_decoder_.get())
result = ERR_INCOMPLETE_CHUNKED_ENCODING;
else
result = ERR_CONTENT_LENGTH_MISMATCH;
}

Il y a également quelques erreurs Varnish 503, qui ne sont pas lié au bug ci-dessus, mais elles me semblent être liées à un des modules PHP chargé sur le serveur qui serait défectueux… Le soucis étant de trouver lequel, car l’erreur dit simplement :

zend_mm_heap corrupted

Et c’est tout… Aucune indication, si ce n’est que ZEND est forcément lié à PHP 🙂 !

Voilà, c’était tout pour ce petit carnet de développeur !