Как устранить ошибки Rack Lint?

Question

Я заметил, что некоторые запросы, особенно от Uptime Robot для проверки работоспособности страницы, недавно начали генерировать следующую ошибку Rack Lint в моем приложении Rails 3.1.x:

21:47:05 web.1     | Started HEAD "/" for 74.86.158.106 at 2012-03-22 21:47:05 -0400
21:47:05 web.1     |   Processing by HomeController#index as */*
...
21:47:05 web.1     | /Users/username/.rvm/gems/ruby-1.9.3-p125@project/gems/activesupport-3.1.4/lib/active_support/core_ext/string/output_safety.rb:23: warning: regexp match /.../n against to UTF-8 string
...
21:47:05 web.1     | Completed 200 OK in 81ms (Views: 60.3ms | ActiveRecord: 0.0ms)
21:47:05 web.1     | 74.86.158.106 - - [22/Mar/2012 21:47:05] "GET / HTTP/1.1" 200 31842 0.1993
21:47:05 web.1     | E, [2012-03-22T21:47:05.546848 #18938] ERROR -- : app error: Content-Length header was 31842, but should be 0 (Rack::Lint::LintError)
21:47:05 web.1     | E, [2012-03-22T21:47:05.546978 #18938] ERROR -- : /Users/username/.rvm/gems/ruby-1.9.3-p125@project/gems/rack-1.3.6/lib/rack/lint.rb:19:in `assert'
21:47:05 web.1     | E, [2012-03-22T21:47:05.547079 #18938] ERROR -- : /Users/username/.rvm/gems/ruby-1.9.3-p125@project/gems/rack-1.3.6/lib/rack/lint.rb:501:in `verify_content_length'
21:47:05 web.1     | E, [2012-03-22T21:47:05.547178 #18938] ERROR -- : /Users/username/.rvm/gems/ruby-1.9.3-p125@project/gems/rack-1.3.6/lib/rack/lint.rb:525:in `each'
21:47:05 web.1     | E, [2012-03-22T21:47:05.547277 #18938] ERROR -- : /Users/username/.rvm/gems/ruby-1.9.3-p125@project/gems/rack-1.3.6/lib/rack/body_proxy.rb:23:in `method_missing'
21:47:05 web.1     | E, [2012-03-22T21:47:05.547375 #18938] ERROR -- : /Users/username/.rvm/gems/ruby-1.9.3-p125@project/gems/unicorn-4.2.0/lib/unicorn/http_response.rb:41:in `http_response_write'
21:47:05 web.1     | E, [2012-03-22T21:47:05.547476 #18938] ERROR -- : /Users/username/.rvm/gems/ruby-1.9.3-p125@project/gems/unicorn-4.2.0/lib/unicorn/http_server.rb:538:in `process_client'
21:47:05 web.1     | E, [2012-03-22T21:47:05.547574 #18938] ERROR -- : /Users/username/.rvm/gems/ruby-1.9.3-p125@project/gems/unicorn-4.2.0/lib/unicorn/http_server.rb:604:in `worker_loop'
21:47:05 web.1     | E, [2012-03-22T21:47:05.547672 #18938] ERROR -- : /Users/username/.rvm/gems/ruby-1.9.3-p125@project/gems/unicorn-4.2.0/lib/unicorn/http_server.rb:487:in `spawn_missing_workers'
21:47:05 web.1     | E, [2012-03-22T21:47:05.547770 #18938] ERROR -- : /Users/username/.rvm/gems/ruby-1.9.3-p125@project/gems/unicorn-4.2.0/lib/unicorn/http_server.rb:137:in `start'
21:47:05 web.1     | E, [2012-03-22T21:47:05.547867 #18938] ERROR -- : /Users/username/.rvm/gems/ruby-1.9.3-p125@project/gems/unicorn-4.2.0/bin/unicorn:121:in `<top (required)>'
21:47:05 web.1     | E, [2012-03-22T21:47:05.547966 #18938] ERROR -- : /Users/username/.rvm/gems/ruby-1.9.3-p125@project/bin/unicorn:19:in `load'
21:47:05 web.1     | E, [2012-03-22T21:47:05.548063 #18938] ERROR -- : /Users/username/.rvm/gems/ruby-1.9.3-p125@project/bin/unicorn:19:in `<main>'

Любые идеи относительно того, что можетздесь происходит?На самом деле я сейчас не нахожу решения, которое бы конкретно касалось того, что делать в этом сценарии, а также выяснения того, что на самом деле может происходить.

Answer 1

Я знаю, что это старый вопрос, но у меня точно такая же проблема.Запросы от UptimeRobot и New Relic (и только от IP-адресов от этих двух) дают эти сообщения журнала.

И UptimeRobot, и NewRelic сообщают «ОК».

Кажется, что это не тот запрос, которыйRack::Lint жалуется, но ответ.Посмотрите на трассировку стека.Он проходит через http_response_write единорога (я тоже использую единорога).

Я расскажу больше и добавлю любые находки здесь.

ОБНОВЛЕНИЕ:

Я могу воспроизвестипроблема с

$ curl https://example.com -X HEAD -i
HTTP/1.1 200 OK
Server: nginx/1.6.2 (Ubuntu)
Date: Wed, 18 Nov 2015 09:17:11 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 18422
Connection: keep-alive
Status: 200 OK
...

curl: (18) transfer closed with 18422 bytes remaining to read

Так что, похоже, мои старые Rails не поддерживают должным образом запросы HEAD.

ОБНОВЛЕНИЕ: Я не могу воспроизвести на моем бродячем ящике или на промежуточном сервере.Единственное отличие от производства, о котором я могу думать, - это SSL.

Answer 2

Похоже, ваш робот Uptime отправляет заголовок с неправильным значением. Он должен отправлять заголовок Content-length со значением 0 (или вообще не отправлять его), но отправляет его с 31842, что, вероятно, неправильно.

Вы можете направить его на какой-нибудь другой http-сервер, сбросить все заголовки и посмотреть, почему он отправляет это, или просто сменить своего робота uptime на , а не отправить этот заголовок.