mongrel unicorn - Aug 2011 - Rack content-length Rack::Lint::LintErrors errors with unicorn

Has anyone seen anything like this before?  I can get it to happen all
the time if I issue a HEAD request, but it only happens very
intermittently on GET requests.

I''m using Ruby 1.9.2p180.

Any ideas on where to start debugging?

204.93.223.151, 10.195.114.81 - - [11/Aug/2011 21:03:50] "GET /
HTTP/1.0" 200 37902 0.5316
app error: Content-Length header was 37902, but should be 0
(Rack::Lint::LintError)
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/rack-1.2.3/lib/rack/lint.rb:19:in
`assert''
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/rack-1.2.3/lib/rack/lint.rb:501:in
`verify_content_length''
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/rack-1.2.3/lib/rack/lint.rb:525:in
`each''
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/unicorn-4.0.1/lib/unicorn/http_response.rb:41:in
`http_response_write''
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/unicorn-4.0.1/lib/unicorn/http_server.rb:526:in
`process_client''
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/unicorn-4.0.1/lib/unicorn/http_server.rb:585:in
`worker_loop''
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/newrelic_rpm-3.0.1/lib/new_relic/agent/instrumentation/unicorn_instrumentation.rb:12:in
`call''
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/newrelic_rpm-3.0.1/lib/new_relic/agent/instrumentation/unicorn_instrumentation.rb:12:in
`block (4 levels) in <top (required)>''
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/unicorn-4.0.1/lib/unicorn/http_server.rb:475:in
`spawn_missing_workers''
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/unicorn-4.0.1/lib/unicorn/http_server.rb:135:in
`start''
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/unicorn-4.0.1/bin/unicorn:121:in
`<top (required)>''
/data/tanga/current/sites/tanga/bin/unicorn:16:in `load''
/data/tanga/current/sites/tanga/bin/unicorn:16:in `<main>''

Joe Van Dyk <joe at tanga.com> wrote:
> Has anyone seen anything like this before?  I can get it to happen all
> the time if I issue a HEAD request, but it only happens very
> intermittently on GET requests.
> 
> I''m using Ruby 1.9.2p180.
> 
> Any ideas on where to start debugging?
What web framework and other middlewares are you running?  Are you using
Rack::Head to
generate HEAD responses or something else?
> 204.93.223.151, 10.195.114.81 - - [11/Aug/2011 21:03:50] "GET /
> HTTP/1.0" 200 37902 0.5316
> app error: Content-Length header was 37902, but should be 0
> (Rack::Lint::LintError)
>
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/rack-1.2.3/lib/rack/lint.rb:19:in
> `assert''
>
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/rack-1.2.3/lib/rack/lint.rb:501:in
> `verify_content_length''
Looking at the 1.2.3 rack/lint.rb code, it should''ve set @head_request
to true
when env["REQUEST_METHOD"] == "HEAD" (rack/lint.rb line 56).
Do you happen to have any middlewares that might rewrite REQUEST_METHOD?

I would edit rack/lint.rb and put some print statements to show the
value of @head_request and env["REQUEST_METHOD"]

-- 
Eric Wong

On Thu, Aug 11, 2011 at 10:42 PM, Eric Wong <normalperson at yhbt.net>
wrote:
> Joe Van Dyk <joe at tanga.com> wrote:
>> Has anyone seen anything like this before? ?I can get it to happen all
>> the time if I issue a HEAD request, but it only happens very
>> intermittently on GET requests.
>>
>> I''m using Ruby 1.9.2p180.
>>
>> Any ideas on where to start debugging?
>
> What web framework and other middlewares are you running? ?Are you using
Rack::Head to
> generate HEAD responses or something else?
Rails 3.0.  I''m not doing anything special with HEAD requests.  I
actually don''t care about the HEAD requests -- you''ll note
that I''m
doing a GET request below.  The Content-Length is 37902 (which is
should be), but apparently there''s nothing in the response body?
>> 204.93.223.151, 10.195.114.81 - - [11/Aug/2011 21:03:50] "GET /
>> HTTP/1.0" 200 37902 0.5316
>> app error: Content-Length header was 37902, but should be 0
>> (Rack::Lint::LintError)
>>
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/rack-1.2.3/lib/rack/lint.rb:19:in
>> `assert''
>>
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/rack-1.2.3/lib/rack/lint.rb:501:in
>> `verify_content_length''
>
> Looking at the 1.2.3 rack/lint.rb code, it should''ve set
@head_request to true
> when env["REQUEST_METHOD"] == "HEAD" (rack/lint.rb line
56).
> Do you happen to have any middlewares that might rewrite REQUEST_METHOD?
>
> I would edit rack/lint.rb and put some print statements to show the
> value of @head_request and env["REQUEST_METHOD"]
>
> --
> Eric Wong
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
>

On Fri, Aug 12, 2011 at 11:09 AM, Joe Van Dyk <joe at tanga.com>
wrote:
> On Thu, Aug 11, 2011 at 10:42 PM, Eric Wong <normalperson at
yhbt.net> wrote:
>> Joe Van Dyk <joe at tanga.com> wrote:
>>> Has anyone seen anything like this before? ?I can get it to happen
all
>>> the time if I issue a HEAD request, but it only happens very
>>> intermittently on GET requests.
>>>
>>> I''m using Ruby 1.9.2p180.
>>>
>>> Any ideas on where to start debugging?
>>
>> What web framework and other middlewares are you running? ?Are you
using Rack::Head to
>> generate HEAD responses or something else?
>
> Rails 3.0. ?I''m not doing anything special with HEAD requests. ?I
> actually don''t care about the HEAD requests -- you''ll
note that I''m
> doing a GET request below. ?The Content-Length is 37902 (which is
> should be), but apparently there''s nothing in the response body?

Here''s another example, the body is apparently empty, but the
content-length is set on a 302 request.  Unfortunately, I can''t
reproduce the problem consistently.  :(  I''d expect the body to not be
0 here.

216.14.95.14, 10.195.114.81 - - [12/Aug/2011 12:00:46] "GET
/deals/current/good_till_gone HTTP/1.0" 302 195 0.0148
app error: Content-Length header was 195, but should be 0
(Rack::Lint::LintError)
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/rack-1.2.3/lib/rack/lint.rb:19:in
`assert''
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/rack-1.2.3/lib/rack/lint.rb:501:in
`verify_content_length''
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/rack-1.2.3/lib/rack/lint.rb:525:in
`each''
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/unicorn-4.0.1/lib/unicorn/http_response.rb:41:in
`http_response_write''
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/unicorn-4.0.1/lib/unicorn/http_server.rb:526:in
`process_client''
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/unicorn-4.0.1/lib/unicorn/http_server.rb:585:in
`worker_loop''
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/newrelic_rpm-3.0.1/lib/new_relic/agent/instrumentation/unicorn_instrumentation.rb:12:in
`call''
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/newrelic_rpm-3.0.1/lib/new_relic/agent/instrumentation/unicorn_instrumentation.rb:12:in
`block (4 levels) in <top (required)>''
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/unicorn-4.0.1/lib/unicorn/http_server.rb:475:in
`spawn_missing_workers''
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/unicorn-4.0.1/lib/unicorn/http_server.rb:135:in
`start''
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/unicorn-4.0.1/bin/unicorn:121:in
`<top (required)>''
/data/tanga/current/sites/tanga/bin/unicorn:16:in `load''
/data/tanga/current/sites/tanga/bin/unicorn:16:in `<main>''

>
>>> 204.93.223.151, 10.195.114.81 - - [11/Aug/2011 21:03:50] "GET
/
>>> HTTP/1.0" 200 37902 0.5316
>>> app error: Content-Length header was 37902, but should be 0
>>> (Rack::Lint::LintError)
>>>
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/rack-1.2.3/lib/rack/lint.rb:19:in
>>> `assert''
>>>
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/rack-1.2.3/lib/rack/lint.rb:501:in
>>> `verify_content_length''
>>
>> Looking at the 1.2.3 rack/lint.rb code, it should''ve set
@head_request to true
>> when env["REQUEST_METHOD"] == "HEAD" (rack/lint.rb
line 56).
>> Do you happen to have any middlewares that might rewrite
REQUEST_METHOD?
>>
>> I would edit rack/lint.rb and put some print statements to show the
>> value of @head_request and env["REQUEST_METHOD"]
>>
>> --
>> Eric Wong
>> _______________________________________________
>> Unicorn mailing list - mongrel-unicorn at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
>> Do not quote signatures (like this one) or top post when replying
>>
>

Joe Van Dyk <joe at tanga.com> wrote:
>
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/newrelic_rpm-3.0.1/lib/new_relic/agent/instrumentation/unicorn_instrumentation.rb:12:in
> `call''
Does disabling newrelic help?  I heard it might not work with Unicorn
4.x, yet.

Maybe someone else has more experience with this, I don''t rely on
non-Free APIs or services like new relic, ever.

-- 
Eric Wong

On Thu, Aug 11, 2011 at 10:42 PM, Eric Wong <normalperson at yhbt.net>
wrote:
> Joe Van Dyk <joe at tanga.com> wrote:
>> Has anyone seen anything like this before? ?I can get it to happen all
>> the time if I issue a HEAD request, but it only happens very
>> intermittently on GET requests.
>>
>> I''m using Ruby 1.9.2p180.
>>
>> Any ideas on where to start debugging?
>
> What web framework and other middlewares are you running? ?Are you using
Rack::Head to
> generate HEAD responses or something else?
Does unicorn use Rack::Lint by default?  What about Rack::ShowBacktrace?

Joe Van Dyk <joe at tanga.com> wrote:
> On Thu, Aug 11, 2011 at 10:42 PM, Eric Wong <normalperson at
yhbt.net> wrote:
> > Joe Van Dyk <joe at tanga.com> wrote:
> >> Has anyone seen anything like this before? ?I can get it to happen
all
> >> the time if I issue a HEAD request, but it only happens very
> >> intermittently on GET requests.
> >>
> >> I''m using Ruby 1.9.2p180.
> >>
> >> Any ideas on where to start debugging?
> >
> > What web framework and other middlewares are you running? ?Are you
using Rack::Head to
> > generate HEAD responses or something else?
> 
> Does unicorn use Rack::Lint by default?  What about Rack::ShowBacktrace?
Yes with RACK_ENV=development, it loads Rack::CommonLogger,
Rack::ShowExceptions and Rack::Lint.  This stack should match what
"rackup" loads in development.

Btw, did you notice my other reply?  I forgot to Cc: you and I''m not
sure if you''re subscribed or not (if via gmane):
  http://mid.gmane.org/20110812223615.GA30885 at dcvr.yhbt.net

-- 
Eric Wong

On Fri, Aug 12, 2011 at 9:51 PM, Eric Wong <normalperson at yhbt.net>
wrote:
> Joe Van Dyk <joe at tanga.com> wrote:
>> On Thu, Aug 11, 2011 at 10:42 PM, Eric Wong <normalperson at
yhbt.net> wrote:
>> > Joe Van Dyk <joe at tanga.com> wrote:
>> >> Has anyone seen anything like this before? ?I can get it to
happen all
>> >> the time if I issue a HEAD request, but it only happens very
>> >> intermittently on GET requests.
>> >>
>> >> I''m using Ruby 1.9.2p180.
>> >>
>> >> Any ideas on where to start debugging?
>> >
>> > What web framework and other middlewares are you running? ?Are you
using Rack::Head to
>> > generate HEAD responses or something else?
>>
>> Does unicorn use Rack::Lint by default? ?What about
Rack::ShowBacktrace?
>
> Yes with RACK_ENV=development, it loads Rack::CommonLogger,
> Rack::ShowExceptions and Rack::Lint. ?This stack should match what
> "rackup" loads in development.
>
> Btw, did you notice my other reply? ?I forgot to Cc: you and I''m
not
> sure if you''re subscribed or not (if via gmane):
> ?http://mid.gmane.org/20110812223615.GA30885 at dcvr.yhbt.net
I thought I subscribed to the mailing list last night, but I''m not
getting any emails.  I just tried to subscribe (by email and by web)
and still haven''t received the confirmation email.

Disabling newrelic had no effect on the bug.

Joe

On Fri, Aug 12, 2011 at 9:51 PM, Eric Wong <normalperson at yhbt.net>
wrote:
> Joe Van Dyk <joe at tanga.com> wrote:
>> On Thu, Aug 11, 2011 at 10:42 PM, Eric Wong <normalperson at
yhbt.net> wrote:
>> > Joe Van Dyk <joe at tanga.com> wrote:
>> >> Has anyone seen anything like this before? ?I can get it to
happen all
>> >> the time if I issue a HEAD request, but it only happens very
>> >> intermittently on GET requests.
>> >>
>> >> I''m using Ruby 1.9.2p180.
>> >>
>> >> Any ideas on where to start debugging?
>> >
>> > What web framework and other middlewares are you running? ?Are you
using Rack::Head to
>> > generate HEAD responses or something else?
>>
>> Does unicorn use Rack::Lint by default? ?What about
Rack::ShowBacktrace?
>
> Yes with RACK_ENV=development, it loads Rack::CommonLogger,
> Rack::ShowExceptions and Rack::Lint. ?This stack should match what
> "rackup" loads in development.
Hm -- RACK_ENV is set to ''production''.  I don''t see
Rack::Lint or
Rack::ShowExceptions when I do ''rake middleware'' on the
servers that
exhibit the bug.

Joe

Joe Van Dyk <joe at tanga.com> wrote:
> On Fri, Aug 12, 2011 at 9:51 PM, Eric Wong <normalperson at yhbt.net>
wrote:
> > Joe Van Dyk <joe at tanga.com> wrote:
> >> On Thu, Aug 11, 2011 at 10:42 PM, Eric Wong <normalperson at
yhbt.net> wrote:
> >> > What web framework and other middlewares are you running?
?Are you using Rack::Head to
> >> > generate HEAD responses or something else?
> >>
> >> Does unicorn use Rack::Lint by default? ?What about
Rack::ShowBacktrace?
> >
> > Yes with RACK_ENV=development, it loads Rack::CommonLogger,
> > Rack::ShowExceptions and Rack::Lint. ?This stack should match what
> > "rackup" loads in development.
> 
> Hm -- RACK_ENV is set to ''production''.  I don''t
see Rack::Lint or
> Rack::ShowExceptions when I do ''rake middleware'' on the
servers that
> exhibit the bug.
"rake middleware" won''t show what the Rack server (Unicorn in
this case)
loads automatically.  If you can, share what "rake middleware"
shows[1]

Also, are you sure it''s RACK_ENV or could it be RAILS_ENV?  If
you''re
sure it''s RACK_ENV=production, then there''s no way it should
load
Rack::Lint behind your back...

Can you share your command-line for launching unicorn?

Are you using "unicorn" or "unicorn_rails"?  The latter was
designed for
Rails 1/2.x, the former may work better with Rails 3 but really both
should work...


[1] Ideally, you''d be able to share the full source +
    configs of your app, but I''m not going to push you to violate NDAs
    and such.  If you can put up an isolated test case that reproduces
    this problem reliably, that''d be awesome, too.

-- 
Eric Wong

Joe Van Dyk <joe at tanga.com> wrote:
> I thought I subscribed to the mailing list last night, but I''m not
> getting any emails.  I just tried to subscribe (by email and by web)
> and still haven''t received the confirmation email.
I just saw your subscription.  I don''t like requiring subscriptions to
post, though.  I''m used to lists where it''s customary/expected
to Cc:
all recipients, but the Ruby world seems to favor[1] subscription-required
mailing lists, however...  (ruby-talk/ruby-core/...)
> Disabling newrelic had no effect on the bug.
Also, is there anything else you use that might hook directly into
Unicorn internals?

Something really feels "off" about the errors you''re getting
from
Rack::Lint.  You''re not running anything super-exotic and I''m
sure
you''re not the only Rails 3.0 + Ruby 1.9.2 user around.

Do you have any other Rails/Rack applications or try other application
servers? (WEBrick/Passenger/Thin/...).


[1] - Sure it seems to favor non-Free operating systems and services,
      too, but I draw the line there.   I am a after all a
      Free Software-only hippie :>

-- 
Eric Wong

On Fri, Aug 12, 2011 at 5:42 AM, Eric Wong <normalperson at yhbt.net>
wrote:
> Joe Van Dyk <joe at tanga.com> wrote:
>> Has anyone seen anything like this before? ?I can get it to happen all
>> the time if I issue a HEAD request, but it only happens very
>> intermittently on GET requests.
>>
>> I''m using Ruby 1.9.2p180.
>>
>> Any ideas on where to start debugging?
>
> What web framework and other middlewares are you running? ?Are you using
Rack::Head to
> generate HEAD responses or something else?
>
>> 204.93.223.151, 10.195.114.81 - - [11/Aug/2011 21:03:50] "GET /
>> HTTP/1.0" 200 37902 0.5316
>> app error: Content-Length header was 37902, but should be 0
>> (Rack::Lint::LintError)
>>
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/rack-1.2.3/lib/rack/lint.rb:19:in
>> `assert''
>>
/mnt/data/tanga/current/bundler/ruby/1.9.1/gems/rack-1.2.3/lib/rack/lint.rb:501:in
>> `verify_content_length''
>
> Looking at the 1.2.3 rack/lint.rb code, it should''ve set
@head_request to true
> when env["REQUEST_METHOD"] == "HEAD" (rack/lint.rb line
56).
> Do you happen to have any middlewares that might rewrite REQUEST_METHOD?
>
> I would edit rack/lint.rb and put some print statements to show the
> value of @head_request and env["REQUEST_METHOD"]
Narrowed this down a little bit more.

Nginx is receiving a HEAD request, unicorn is logging a GET.
Somewhere along the chain, the http method is getting mangled.

(I''m seeing a lot of these errors because newrelic is sending HEAD
requests to check if the site is up.)

Joe Van Dyk <joe at tanga.com> wrote:
> Narrowed this down a little bit more.
> 
> Nginx is receiving a HEAD request, unicorn is logging a GET.
> Somewhere along the chain, the http method is getting mangled.
That''s not good.  I''m pretty sure all versions of nginx send
HEAD
requests as-is to Unicorn, so something in your Rack middleware stack is
rewriting HEAD => GET.

You can strace  a Unicorn worker to confirm it receives a HEAD and not a
GET at the socket level.  Do it on a server that''s not receiving any
other traffic and use one worker process so you''re always stracing the
correct worker process.

-- 
Eric Wong

On Mon, Aug 22, 2011 at 1:38 PM, Eric Wong <normalperson at yhbt.net>
wrote:
> Joe Van Dyk <joe at tanga.com> wrote:
>> Narrowed this down a little bit more.
>>
>> Nginx is receiving a HEAD request, unicorn is logging a GET.
>> Somewhere along the chain, the http method is getting mangled.
>
> That''s not good. ?I''m pretty sure all versions of nginx
send HEAD
> requests as-is to Unicorn, so something in your Rack middleware stack is
> rewriting HEAD => GET.
>
> You can strace ?a Unicorn worker to confirm it receives a HEAD and not a
> GET at the socket level. ?Do it on a server that''s not receiving
any
> other traffic and use one worker process so you''re always stracing
the
> correct worker process.
I started a new Rails application at
https://github.com/joevandyk/unicorn-head-requests

When I send unicorn a HEAD request, it logs it as a GET.  This shows
up in the unicorn log:
127.0.0.1 - - [23/Aug/2011 11:15:38] "GET / HTTP/1.1" 200 - 0.0231

But this is what shows up in Rails:
Started HEAD "/" for 127.0.0.1 at 2011-08-23 11:15:58 -0700
  Processing by WelcomeController#index as

On Tue, Aug 23, 2011 at 11:22 AM, Joe Van Dyk <joe at tanga.com>
wrote:
> On Mon, Aug 22, 2011 at 1:38 PM, Eric Wong <normalperson at yhbt.net>
wrote:
>> Joe Van Dyk <joe at tanga.com> wrote:
>>> Narrowed this down a little bit more.
>>>
>>> Nginx is receiving a HEAD request, unicorn is logging a GET.
>>> Somewhere along the chain, the http method is getting mangled.
>>
>> That''s not good. ?I''m pretty sure all versions of
nginx send HEAD
>> requests as-is to Unicorn, so something in your Rack middleware stack
is
>> rewriting HEAD => GET.
>>
>> You can strace ?a Unicorn worker to confirm it receives a HEAD and not
a
>> GET at the socket level. ?Do it on a server that''s not
receiving any
>> other traffic and use one worker process so you''re always
stracing the
>> correct worker process.
>
> I started a new Rails application at
> https://github.com/joevandyk/unicorn-head-requests
>
> When I send unicorn a HEAD request, it logs it as a GET. ?This shows
> up in the unicorn log:
> 127.0.0.1 - - [23/Aug/2011 11:15:38] "GET / HTTP/1.1" 200 -
0.0231
>
> But this is what shows up in Rails:
> Started HEAD "/" for 127.0.0.1 at 2011-08-23 11:15:58 -0700
> ?Processing by WelcomeController#index as
I tracked down the exception to a bug in a Rack middleware.  But --
unicorn should be logging HEAD requests as a HEAD request (and not a
GET), right?

Joe

On Tue, Aug 23, 2011 at 11:29 AM, Joe Van Dyk <joe at tanga.com>
wrote:
> On Tue, Aug 23, 2011 at 11:22 AM, Joe Van Dyk <joe at tanga.com>
wrote:
>> On Mon, Aug 22, 2011 at 1:38 PM, Eric Wong <normalperson at
yhbt.net> wrote:
>>> Joe Van Dyk <joe at tanga.com> wrote:
>>>> Narrowed this down a little bit more.
>>>>
>>>> Nginx is receiving a HEAD request, unicorn is logging a GET.
>>>> Somewhere along the chain, the http method is getting mangled.
>>>
>>> That''s not good. ?I''m pretty sure all versions of
nginx send HEAD
>>> requests as-is to Unicorn, so something in your Rack middleware
stack is
>>> rewriting HEAD => GET.
>>>
>>> You can strace ?a Unicorn worker to confirm it receives a HEAD and
not a
>>> GET at the socket level. ?Do it on a server that''s not
receiving any
>>> other traffic and use one worker process so you''re always
stracing the
>>> correct worker process.
>>
>> I started a new Rails application at
>> https://github.com/joevandyk/unicorn-head-requests
>>
>> When I send unicorn a HEAD request, it logs it as a GET. ?This shows
>> up in the unicorn log:
>> 127.0.0.1 - - [23/Aug/2011 11:15:38] "GET / HTTP/1.1" 200 -
0.0231
>>
>> But this is what shows up in Rails:
>> Started HEAD "/" for 127.0.0.1 at 2011-08-23 11:15:58 -0700
>> ?Processing by WelcomeController#index as
>
> I tracked down the exception to a bug in a Rack middleware. ?But --
> unicorn should be logging HEAD requests as a HEAD request (and not a
> GET), right?
Ok -- this officially isn''t a unicorn bug.  :)  Something in Rails (or
something Rails uses).

With a HEAD request, env["REQUEST_METHOD"] inside Rack::Lint, is
''GET''.  Only happens with Rails (tried it in 3.0 and 3.1). 
Doesn''t
happen with Sinatra.

Joe

Joe Van Dyk <joe at tanga.com> wrote:
> Ok -- this officially isn''t a unicorn bug.  :)  Something in Rails
(or
> something Rails uses).
Alright, good to know.  I was just running bundler your app when I saw
this message :)

-- 
Eric Wong