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

[#1719] Fix missing headers before error! call #1869

Merged
merged 2 commits into from Mar 12, 2019

Conversation

anaumov
Copy link
Contributor

@anaumov anaumov commented Mar 11, 2019

Fix issue with empty headers after error! method call #1719

It happened when headers were set in before block or endpoint body.

@dblock
Copy link
Member

dblock commented Mar 11, 2019

I do see what you're trying to do, but this may possibly not be the right fix because error! is now merging headers systematically. I realize no other specs break, but someone is bound to get burnt by it, no?

Please fix the CHANGELOG either way to get a green build.

@@ -135,6 +135,7 @@ def version
# @param message [String] The message to display.
# @param status [Integer] the HTTP Status Code. Defaults to default_error_status, 500 if not set.
def error!(message, status = nil, headers = nil)
headers = headers.present? ? header.merge(headers) : header
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a lot of header vs. headers going on here. I would rename headers = nil into additional_headers and use headers everywhere else in the body of this method as header and headers are aliases for semantic reasons: use header when accessing one and use headers when accessing all.

@anaumov
Copy link
Contributor Author

anaumov commented Mar 12, 2019

@dblock thanks for a quick review! I've updated naming (headers -> additional_headers). There is something about header and headers. They are not aliases in the spec.

If I set puts "headers: #{headers}, header: #{header}" here https://github.com/anaumov/grape/blob/fix/headers_in_error_call/lib/grape/dsl/inside_route.rb#L139 and run bundle exec rspec spec/grape/endpoint_spec.rb:1100, output will be:

headers: {"Host"=>"example.org", "Cookie"=>""}, header: {"X-Test"=>"sample"}

I suspect it comes from the request.rb https://github.com/anaumov/grape/blob/fix/headers_in_error_call/lib/grape/request.rb#L30, but I'm not sure how to handle this.

I realize no other specs break, but someone is bound to get burnt by it, no?

It's possible if user supposes that headers should be blanked after error! method call. But such behavior is not documented.

@@ -134,8 +134,9 @@ def version
#
# @param message [String] The message to display.
# @param status [Integer] the HTTP Status Code. Defaults to default_error_status, 500 if not set.
def error!(message, status = nil, headers = nil)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know it wasn't there, but lets document additional_headers above?

@dblock
Copy link
Member

dblock commented Mar 12, 2019

I realize no other specs break, but someone is bound to get burnt by it, no?

It's possible if user supposes that headers should be blanked after error! method call. But such behavior is not documented.

Could you please document the new behavior in README, add a note to UPGRADING and write a spec that ensures the headers are actually merged as part of this PR? Thank you.

@anaumov
Copy link
Contributor Author

anaumov commented Mar 12, 2019

@dblock I've added docs and specs. Let me know if any corrections needed. Should I squash and rebase?

@dblock dblock merged commit ab184d1 into ruby-grape:master Mar 12, 2019
@dblock
Copy link
Member

dblock commented Mar 12, 2019

I squashed and merged. Thank you. Shoot an email to the grape mailing list describing this change and see what people say about it? Ask whether we need to support the previous behavior.

@anaumov
Copy link
Contributor Author

anaumov commented Mar 13, 2019

@dblock cool! I sent an email.

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

Successfully merging this pull request may close these issues.

None yet

2 participants