Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return 406 status for unsupported formats #446

Merged
merged 1 commit into from Aug 14, 2017
Merged

Return 406 status for unsupported formats #446

merged 1 commit into from Aug 14, 2017

Conversation

@fofr
Copy link
Contributor

@fofr fofr commented Aug 14, 2017

When a request is made for an unsupported format, eg text/javascript, the lack of a respond_to block meant we attempted to render it without a layout.

This led to a body being sent to slimmer without a #wrapper element,
causing the error:
> undefined method 'to_html' for nil:NilClass
in the BodyInserter processor

  • Add a respond_to block to respond only to known formats
  • Catch unknown format errors and return 406 (not acceptable)

This matches: alphagov/finder-frontend#271

format.html must come before format.atom in the block. If a browser sends an unspecific accepts header, eg */*, Rails falls through to the first format/variant declared in respond_to.

See also: alphagov/multipage-frontend#23

When a request is made for an unsupported format, eg text/javascript,
the lack of a respond_to block meant we attempted to render it without
a layout.

This led to a body being sent to slimmer without a #wrapper element,
causing the error:
`> undefined method `to_html' for nil:NilClass` in the BodyInserter
processor

* Add a respond_to block to respond only to known formats
* Catch unknown format errors and return 406 (not acceptable)

This matches: alphagov/finder-frontend#271

`format.html` must come before `format.atom` in the block. If a browser
sends an unspecific accepts header, eg `*/*`,
Rails falls through to the first format/variant declared in `respond_to`.

See also: alphagov/multipage-frontend#23
@boffbowsh boffbowsh temporarily deployed to government-frontend-pr-446 Aug 14, 2017 Inactive
Copy link
Contributor

@thomasleese thomasleese left a comment

Looks good to me!

@fofr fofr merged commit ca7651d into master Aug 14, 2017
1 check passed
1 check passed
security/snyk No new vulnerabilities
Details
@fofr fofr deleted the no-accepts branch Aug 14, 2017
assert_select '#wrapper'
end

test "returns a 406 for XMLHttpRequests" do

This comment has been minimized.

@boffbowsh

boffbowsh Aug 14, 2017
Contributor

I think the only reason this is ok at the moment is because we don't have CORS headers that allow use of our HTML content from other sites anyway, and we know we're not (currently) loading content via Ajax. Otherwise I would think that GETting HTML in a Javascript context would be acceptable.

I'm not sure what to think about this.

This comment has been minimized.

@fofr

fofr Aug 14, 2017
Author Contributor

I think the test name is misleading, sorry. This was intended to test Rails’s behaviour of falling back to a text/javascript format as a default when using XMLHttpRequests.

If you make an XMLHttpRequest with "Accepts: text/html", you will still receive an HTML response.

This comment has been minimized.

@fofr

fofr Aug 14, 2017
Author Contributor

(Aside: Passing an empty Accepts: header in minitest appears to get ignored.)

This comment has been minimized.

@fofr

fofr Aug 15, 2017
Author Contributor

Fixed in f1ba8ad

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.