- 
          
- 
                Notifications
    You must be signed in to change notification settings 
- Fork 1.2k
Detect content type correctly if raised any low level errors #1427
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
base: master
Are you sure you want to change the base?
Conversation
be0cd76    to
    b69cce5      
    Compare
  
    | Why would we want to swallow this error here? I would think it should just go upstream and be handled by whatever  | 
| @dblock That's exactly what I'm doing. I have  rescue_from Rack::Utils::ParameterTypeError do |e|
  error_model = Models::Error.new(e)
  error!({
    errors: Serializers::Errors.new.serialize([error_model])
  }, error_model.status_code, 'Content-Type' => 'application/json')
endThis patch is only for detecting the response content type correctly. That's not for handling Rack level errors. Thanks | 
b69cce5    to
    f0d9647      
    Compare
  
    | I get it, I'm cool with merging it on green. | 
        
          
                CHANGELOG.md
              
                Outdated
          
        
      |  | ||
| #### Fixes | ||
|  | ||
| * [#1427](https://github.com/ruby-grape/grape/pull/1427): Detect content type in case of raising Rack level errors - [@iCEAGE](https://github.com/iCEAGE) | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing a period at the end.
I think the description is a bit misleading. Your problem is content type, but what is being fixed is about handling an invalid query string when trying to detect the response format, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes you're right. I updated the description. Thanks
If Rack level errors raise, content type of the request couldn't be detected correctly. Basically there are two types of errors might happen in Rack level, Rack::Utils::ParameterTypeError and Rack::Utils::InvalidParameterError.\n Passing query parameters like `x[y]=1&x[y]z=2` and `foo%81E=1` will raise the Rack level errors and the content type couldn't be detected correctly.
f0d9647    to
    bba1a9d      
    Compare
  
    | 
 As I said earlier in the patch description  | 
| If you're missing a require then obviously yes. Why doesn't it fail on Ruby 2.3.0? | 
If Rack level errors raise, content type of the request couldn't be detected correctly. Basically there are two types of errors might happen in Rack level, Rack::Utils::ParameterTypeError and Rack::Utils::InvalidParameterError.
Passing query parameters like
x[y]=1&x[y]z=2andfoo%81E=1will raise the Rack level errors and the content type couldn't be detected correctly.PS:
appraisal rake specraises two errors which are related to autoloading in Rails. How can I solve this problem?