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

Grape allows invalid headers to be set. #2334

Open
ioquatix opened this issue Jun 6, 2023 · 5 comments
Open

Grape allows invalid headers to be set. #2334

ioquatix opened this issue Jun 6, 2023 · 5 comments
Labels

Comments

@ioquatix
Copy link
Contributor

ioquatix commented Jun 6, 2023

Follow up from socketry/protocol-rack#2 (comment).

The following implementation allows non-string header values.

val ? header[key.to_s] = val : header.delete(key.to_s)

Technically, all headers should be strings, according to the rack spec.

header "x-foo", 123

I'm not sure if we should change this. I see several options:

  • Emit a warning if it's not a string.
  • Convert values to a string.
  • Do nothing.
  • Later on, map @header key values to string values, (or array of string values, allowed by Rack 3+).
@dblock
Copy link
Member

dblock commented Jun 6, 2023

For Grape users, is the real issue is that it works in Grape with Rack 2.x and not 3.x causing a NoMethodError: undefined method split' for 2:Integer`? If so, I think we should do nothing and document that upgrading to Rack 3 causes this. We could error early with "rack 3 doesn't support non-string values", too.

@dblock dblock added the bug? label Jun 6, 2023
@dblock
Copy link
Member

dblock commented Jun 6, 2023

Other breaking changes with Rack 3, #2298.

@ioquatix
Copy link
Contributor Author

ioquatix commented Jun 6, 2023

No, it's nothing to do with Rack 3, it's always been invalid, even Rack 2 spec does not allow non-string header values.

@dblock
Copy link
Member

dblock commented Jun 7, 2023

But it works for users today, except when otherwise (described in socketry/protocol-rack#2). I think Grape should adhere to spec. I like the option of doing .to_s on header values, because it's backwards-compatible, but we should look at whether any specs break with that.

@ioquatix
Copy link
Contributor Author

ioquatix commented Jun 7, 2023

If you put Rack::Lint in front of the apps (e.g. during testing/CI) it will fail.

I think you should encourage people to use Rack::Lint behind Grape in CI. It will report the problem.

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

No branches or pull requests

2 participants