Qu'est-ce que «WARN n'a pas pu déterminer la longueur du contenu du corps de la réponse». veux dire et comment m'en débarrasser?


320

Depuis la mise à niveau vers Rails 3.1, je vois ce message d'avertissement dans mon journal de développement:

WARN Impossible de déterminer la longueur du contenu du corps de la réponse. Définir la longueur du contenu de la réponse ou définirResponse#chunked = true

Qu'est-ce que cela signifie et comment puis-je le supprimer? C'est un problème?


1
Même chose ici, pour moi, ça se passe quand c'est un appel à distance via JS.
Tim Baas

2
J'ai commencé à l'obtenir dès que je suis passé à Ruby 1.9.3 aujourd'hui. Je ne le voyais pas avant. Je pense que cela doit être dû à des changements dans WEBrick dans Ruby 1.9.3 ...
Tyler Rick

50
C'est en effet un problème WEBrick. En attendant, vous pouvez ajouter la gemme «mince» à votre Gemfile et démarrer Rails avec cela au lieu de WEBrick, par exemple rails s thin; Ta-da! Plus d'avertissements.
Scott

Réponses:


229

Poser la même question à l'un des membres de Rails-Core:

https://twitter.com/luislavena/status/108998968859566080

Et la réponse:

https://twitter.com/tenderlove/status/108999110136303617

oui, ça va. Besoin de le nettoyer, mais rien n'est blessé.


9
fyi, si les messages vous dérangent, vous pouvez utiliser une solution de contournement mince (ajoutez gem 'thin'à votre gemfile, démarrez votre serveur en utilisant rails server thin). (oups, je viens de remarquer que @Scott Lowe l'a déjà dit ci-dessus.)
fearless_fool

280
Je trouve cela ennuyeux lorsque ce genre de choses est placé dans la catégorie «rien n'est blessé». Le simple fait que des milliers de personnes perdent du temps à comprendre ce qui se passe est suffisant pour contester cela.
Mark Fraser

16
@KenThompson, le problème est Webrick, pas Rails. Webrick ne prend pas en charge les connexions persistantes et soulève donc l'avertissement / problème que nous voyons. Il est recommandé d'utiliser un serveur Web approprié / meilleur (comme un serveur autonome léger ou passager) pour le Web. Les prochaines versions de Ruby résoudront ce problème.
Luis Lavena

3
Le serveur webrick de notre PC de développement affiche deux fois le même fichier .js.erb. Le problème de rendu double disparaît sur notre serveur de production qui exécute nginx. C'est donc un VRAI problème dans des cas comme le nôtre.
user938363

2
La réponse doit contenir le contenu des messages Twitter au lieu de liens.
Pedro Rolo

78

Le patch suivant a résolu le problème dans mon cas; plus d'avertissement pour moi.

204_304_keep_alive.patch

Modifiez simplement le fichier httpresponse.rb à la ligne 205 comme indiqué sur le lien ci-dessus; en fait, le lien montre une correction apportée à une future version de Ruby.

J'utilise les rails 3.2.0 sur ruby ​​1.9.3-p0 installé via RVM en tant qu'utilisateur unique. L'emplacement dans mon cas est donc:

~/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/webrick/httpresponse.rb

L'emplacement du fichier à modifier diffère selon le type d'installation, RVM ou non, ou même multi-utilisateur ou mono-utilisateur, donc je n'en donne que la dernière partie:

.../ruby-1.9.3-p0/lib/ruby/1.9.1/webrick/httpresponse.rb

J'espère que cela peut être utile à quelqu'un.

EDIT: C'est le lien vers le commit qui a modifié la ligne en question dans la branche trunk du projet ruby.


J'utilise debian squeeze, apt installé ruby ​​version 1.9.3p194, et ce problème persiste. Ruby est daté du 20/04/2012 et le patch de tenderlove est daté du 13 décembre 07:30:14 2011, mais cela se produit toujours.
kristianp

Sur Debian Squeeze, la version 1.9.3-p327 de Ruby installée sur RVM WEBrick donne toujours ces avertissements problématiques.
MarkDBlackwell

56

L'ajout explicite de la gemme au Gemfile s'est débarrassé des messages d'avertissement pour moi:

group :development do
  gem 'webrick', '~> 1.3.1'
end

5
Oui, pour moi aussi. Un indice de la raison pour laquelle cela fonctionne peut être dans la bibliothèque standard de la fonctionnalité # 5481 Gemifying Ruby : "En raison de" fausses pierres précieuses ", les nouveaux fichiers d'un stdlib installé par" gem update "sont ignorés, sauf si un utilisateur écrit explicitement gem [" webrick "] explicitement . "
MarkDBlackwell

2
C'est tellement mieux que «l'ignorer», ou «patcher une brique». Je vous remercie!
nessur

54

Vous pouvez également utiliser Thin au lieu du Webrick par défaut. Ajoutez ceci àGemfile gem 'thin'

puis rails s thinutilisera mince, et l'avertissement disparaîtra.


Oui. C'est ce que j'ai fini par faire ces derniers mois. Ryan Bates a également mentionné dans un récent Railscast.
Nate Bird

1
@cam song: presque correct: les rails minces utiliseront mince au lieu de Webrick, et l'avertissement disparaîtra.
fearless_fool

1
Je mets thinen developmentgroupe. Rails 4 semble le ramasser automatiquement lors de l'exécutionrails s
tirage

15

Si vous utilisez .rvm, procédez comme suit pour le corriger ...

Comme l'a mentionné João Soares , tous ses remerciements, c'est ce que vous pouvez faire si vous ne voulez pas vous débarrasser de cet avertissement sur le développement.

  1. Utilisez votre éditeur préféré pour ouvrir ce fichier:

    ~/.rvm/rubies/<ruby-version>/lib/ruby/1.9.1/webrick/httpresponse.rb
  2. Allez à la ligne qui contient ceci (pour moi, c'était vraiment la ligne 206):

    if chunked? || @header['content-length']
  3. Modifiez-le, extrait de ce patch , en ceci:

    if chunked? || @header['content-length'] || @status == 304 || @status == 204
  4. Enregistrez le fichier et redémarrez éventuellement votre serveur rails


1
Je vous remercie! C'était line 107pour moi.
gbdev

12

Ce problème a été corrigé dans la branche du tronc de Ruby avec ce commit sur webrick.

Vous pouvez modifier ce fichier webrick particulier de manière similaire dans votre configuration. L'emplacement approximatif peut être trouvé par:

gem which webrick

Pour modifier réellement le fichier:

nano \`ruby -e"print %x{gem which webrick}.chomp %Q{.rb\n}"\`/httpresponse.rb

(Ou au lieu de nano, utilisez votre éditeur préféré.)


Ma ligne de commande fantaisie ci-dessus (avec humour, y compris l'éditeur, nano) a été levée sans attribution et protégée par le droit d'auteur sur le site RailsRock ici .
MarkDBlackwell

Les contre-coups ne devraient probablement pas être échappés. Donc , il devrait vraiment être: nano `ruby -e"print %x{gem which webrick}.chomp %Q{.rb\n}"`/httpresponse.rb.
MarkDBlackwell

5

Version JRuby: Si vous utilisez .rvm, faites-le pour le corriger ...

Comme mentionné par João Soares et Kjellski , c'est ce que vous pouvez faire si vous voulez vous débarrasser de cet avertissement sur le développement et que vous utilisez JRuby.

  1. Utilisez votre éditeur préféré pour ouvrir ce fichier:

    ~/.rvm/rubies/jruby-<version>/lib/ruby/<1.8 or 1.9>/webrick/httpresponse.rb
  2. Allez à la ligne qui contient ceci (pour moi, c'était la ligne 205):

    if chunked? || @header['content-length']
  3. Modifiez-le, extrait de ce patch , en ceci:

    if chunked? || @header['content-length'] || @status == 304 || @status == 204
  4. Enregistrez le fichier et redémarrez éventuellement votre serveur rails.


@schwabsauce À l'exception de la première instruction, le reste n'est pas spécifique à JRuby; il aide à localiser le fichier. Les autres instructions sont répétées pour plus de clarté.
Crimbo

3

Une autre solution de contournement qui supprime la ligne incriminée de webrick. Ce n'est tout simplement pas très utile:

cd `which ruby`/../../lib/ruby/1.9.1/webrick/ && sed -i '.bak' -e'/logger.warn/d' httpresponse.rb

(vous devrez peut-être sudo)


3

Ajouter

config.middleware.use Rack::ContentLength

dans votre application.rbfichier, et l'avertissement disparaîtra même avec webrick. Cela sera également Content-Lengthcorrectement défini en production lors du rendu d'une réponse json ou texte.


J'adore l'idée de résoudre réellement le problème au lieu de le cacher avec le patch Keep-Alive. Malheureusement, cette suggestion a simplement craché deux fois plus d'avertissements.
labyrinthe
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.