Projet

Général

Profil

Bug #16690

logger en mode DEBUG : 'utf8' codec can't decode ...

Ajouté par Thomas Noël il y a presque 7 ans. Mis à jour il y a plus de 5 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
-
Version cible:
-
Début:
05 juin 2017
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:

Description

UnicodeDecodeError at /truc/machin/
'utf8' codec can't decode byte 0xc3 in position 4095: unexpected end of data

Ça vient de passerelle/utils/__init__.py :

        # log only if content type is allowed
        if content_type_match(response.headers.get('Content-Type')):
            content = response.content[:settings.LOGGED_RESPONSES_MAX_SIZE]
            self.logger.debug('Response Content: %r' % content,
                              extra={'requests_response_content': content})

En effet, si le 4095ème octet est au milieu d'un caractère unicode genre «vers\xc3\xa9e», alors «vers\xc3» provoque un crash lors de la conversion.

Une piste pourrait être : « ... extra={'requests_response_content': '%r' % content} » ?


Fichiers


Demandes liées

Lié à Passerelle - Bug #15942: erreur lors du logging des chaînes en utf-8Fermé21 avril 2017

Actions

Révisions associées

Révision 6329a2a8 (diff)
Ajouté par Frédéric Péters il y a presque 7 ans

utils: don't break on response content cut in the middle of a character (#16690)

Révision 507f0994 (diff)
Ajouté par Frédéric Péters il y a presque 7 ans

misc: adapt test to change in requests_response_content logging (#16690)

Historique

#1

Mis à jour par Benjamin Dauvergne il y a presque 7 ans

Il faut simplement passer la chaîne de formatage principale en unicode, ensuite tout se passe généralement bien (logging se débrouille mieux avec des chaînes unicode qu'un mix ascii/utf-8).

#2

Mis à jour par Thomas Noël il y a presque 7 ans

Benjamin Dauvergne a écrit :

Il faut simplement passer la chaîne de formatage principale en unicode, ensuite tout se passe généralement bien (logging se débrouille mieux avec des chaînes unicode qu'un mix ascii/utf-8).

J'ai pas bien compris ce que ça implique ; ici c'est extra={'requests_response_content': content} qui pose un soucis, car plus loin dans le logeur spécifique passerelle on enregistre l'extra dans un champ JsonField, et c'est là que ça casse.

#3

Mis à jour par Benjamin Dauvergne il y a presque 7 ans

Ha ok oubliez moi. À noter que l'encodeur JSON standard accepte sans souci une str encodée en UTF-8, donc il y a un souci différent d'un simple problème d'encodage.

#4

Mis à jour par Thomas Noël il y a presque 7 ans

En fait c'est le «response.content[:settings.LOGGED_RESPONSES_MAX_SIZE]» qui pose problème quand il coupe le contenu en plein milieu d'un caractère encodé sur 16bits.

#5

Mis à jour par Frédéric Péters il y a presque 7 ans

-                              extra={'requests_response_content': content})
+                              extra={'requests_response_content': repr(content)})

M'irait, plutôt que '%r' % content.

Et j'ai les yeux qui saignent de cette méthode (espaces qui manquent et font des trucs très laids).

#6

Mis à jour par Thomas Noël il y a presque 7 ans

Ack

#7

Mis à jour par Frédéric Péters il y a presque 7 ans

  • Statut changé de En cours à Résolu (à déployer)
commit 6329a2a80907d46c1cc1c3851e8450fab7cda419
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Fri Jun 23 14:24:05 2017 +0200

    utils: don't break on response content cut in the middle of a character (#16690)
#8

Mis à jour par Josué Kouka il y a presque 7 ans

  • Lié à Bug #15942: erreur lors du logging des chaînes en utf-8 ajouté
#9

Mis à jour par Benjamin Dauvergne il y a plus de 5 ans

  • Statut changé de Résolu (à déployer) à Fermé

Formats disponibles : Atom PDF