Google Chrome et l'erreur net::ERR_INCOMPLETE_CHUNKED_ENCODING
Google Chrome et l'erreur net::ERR_INCOMPLETE_CHUNKED_ENCODING

Bug net::ERR_INCOMPLETE_CHUNKED_ENCODING entre Google Chrome et admin-ajax.php (WordPress)

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 !

SuzuKube

Webmaster d’Otakugame.fr, je tente ici de vous montrer ma « vie de blogueur » et de « développeur web » !

4 Responses

  1. SuzuKube dit :

    Pour les soucis avec Chrome, c’était bien lié à Gzip ! En réécrivant proprement ma configuration, le problème s’en est allé… Ouf !

    Voici, à titre d’exemple, ma configuration à ce niveau (Apache) :


    SetOutputFilter DEFLATE

    # Netscape 4.x has some problems…
    BrowserMatch ^Mozilla/4 gzip-only-text/html

    # Netscape 4.06-4.08 have some more problems
    BrowserMatch ^Mozilla/4\.0[678] no-gzip

    # MSIE masquerades as Netscape, but it is fine
    # BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

    # NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48
    # the above regex won’t work. You can use the following
    # workaround to get the desired effect:
    BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

    # Don’t compress images
    SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png)$ no-gzip dont-vary


    # Make sure proxies don’t deliver the wrong content
    Header append Vary User-Agent env=!dont-vary


    mod_gzip_static_suffix .gz
    AddEncoding gzip .gz
    AddEncoding gzip .gzip
    mod_gzip_on YES
    mod_gzip_handle_methods GET
    mod_gzip_temp_dir /tmp
    mod_gzip_can_negotiate Yes
    mod_gzip_dechunk Yes
    mod_gzip_send_vary On
    mod_gzip_update_static No
    mod_gzip_keep_workfiles No
    mod_gzip_minimum_file_size 250
    mod_gzip_maximum_file_size 1048576
    mod_gzip_maximum_inmem_size 60000
    mod_gzip_min_http 1000
    mod_gzip_item_exclude reqheader « User-agent: Mozilla/4.0[678] »
    mod_gzip_item_exclude file .js$
    mod_gzip_item_exclude file .css$
    mod_gzip_item_exclude mime ^application/pdf$
    mod_gzip_item_exclude mime ^image/
    mod_gzip_item_exclude mime ^application/x-javascript$
    mod_gzip_item_include mime ^text/.*
    mod_gzip_item_include file .html$
    mod_gzip_item_include file .pl$
    mod_gzip_item_include file .cgi$
    mod_gzip_item_include handler ^cgi-script$
    mod_gzip_item_include mime ^httpd/unix-directory$
    mod_gzip_item_include mime ^application/postscript$

  2. SuzuKube dit :

    Bon, malgré cela, j’ai toujours les mêmes erreurs de façon aléatoire, uniquement avec Chrome… Curieux.

  3. SuzuKube dit :

    Aucune solution n’ayant marché, j’ai carrément supprimé l’ajax du site… Dommage !

Laisser un commentaire