Rails 5 / Rspec 3.5.0 -- setting request headers?

[ledbettj]

Hi,

I had a spec working under Rails 4 / Rspec 3.4.4 that looked like this:

it 'does something with the referrer' do
  allow(request).to receive(:referrer).and_return('aol.com')
  expect(Foo).to receive(:bar).with('aol.com')
  get :endpoint
end

After upgrading, it looks like request.referrer is not stubbed correctly and request.referrer in the controller returns nil.

I tried rewriting like so:

get :endpoint, { params: {} }, headers: { 'HTTP_REFERER' => 'aol.com' }

But I wasn't able to get that header, or actually any header passed through to the controller.

Any suggestions?

[ledbettj]

Setting the header in request.env works -- is that the recommended way to accomplish this?

[JonRowe]

Try: get :endpoint, params: {}, headers: { 'HTTP_REFERER' => 'aol.com' }

[fables-tales]

@ledbettj
Thanks for the issue. We need a little more detail to be able to reproduce this.

Could you please provide us with a rails app that we can clone that demonstrates the issue. Specifically it'd be great if

1. you could rails new an application and commit
2. make all the changes necessary to reproduce the issue and commit

then, provide us with a description of how to clone your application and reproduce the issue.

Thanks :)

[ledbettj]

I've pushed a basic example here.

ApplicationController#index simply renders the HTTP referrer as JSON. The specs for this action try to set the referrer in several ways; only the last -- setting request.env -- works.

git clone https://github.com/ledbettj/rspec-repro.git repro
cd repro
bundle
bundle exec rake spec

Output:

Failures:

  1) ApplicationController when stubbing referrer sets the referrer correctly
     Failure/Error: expect(body['from']).to eq(aol)

       expected: "aol.com"
            got: nil

       (compared using ==)
     # ./spec/controllers/application_controller_spec.rb:11:in `block (3 levels) in <top (required)>'

  2) ApplicationController when passing referrer as a hash sets the referrer correctly
     Failure/Error: expect(body['from']).to eq(aol)

       expected: "aol.com"
            got: nil

       (compared using ==)
     # ./spec/controllers/application_controller_spec.rb:18:in `block (3 levels) in <top (required)>'

  3) ApplicationController when passing in two hashes sets the referrer correctly
     Failure/Error: expect(body['from']).to eq(aol)

       expected: "aol.com"
            got: nil

       (compared using ==)
     # ./spec/controllers/application_controller_spec.rb:25:in `block (3 levels) in <top (required)>'

Finished in 0.04602 seconds (files took 2.82 seconds to load)
4 examples, 3 failures

Let me know if anything else would help.

[richddr]

request.env did not work for me. Any update on this?

[fables-tales]

@richddr looks like nobody from the RSpec core team has had a chance to look at this yet. If you really need a fix to this, you're more than welcome to use the reproduction case above as a starting point for debugging and see if you can fix the problem :)

[sebastian-julius]

I worked around this like so. Maybe it helps you, too. Not the prettiest solution but effective.

  let(:headers) { some: "header" }
  # ...
  request.headers.merge! headers
  post :endpoint, params: params

[monorkin]

I tried to fix this issue but don't see anything wrong with the way it currently is. (I don't know if this is a regression)

Just to explain as to why this is happening.

Regarding the stubbed method. If you take a look at ActionController::TestCase::Behaviour you will notice that all HTTP methods (get, post, delete, ...) get funneled into the process method. The process method builds a new TestRequest object with the request.env object from your test. That's why stubbed methods won't work.

Regarding the remaining two options - passing the headers as params. This also won't work. If you take a look at the above-mentioned class you can notice that only the session, flash, method, body, xhr params get processed and all others are ignored.

This leaves you with the option to edit request.env direcly or through request.headers as @sebastian-julius outlined.