updating to '>= 1.0.4' leads to missing ressource headers for OPTIONS requests

[jethroo]

Hi there,

we currently update to our rack-cors dependency to close the CVE to a newer patch level but we are noticing breaking behaviour changes:

With the following ressource with gem version 1.0.1

    resource '/evaluations/*',
      headers: ['Origin', 'X-Requested-With', 'Content-Type', 'Accept', 'Authorization'],
      methods: %i[get post options put]

we were getting back our rails application headers when doing an OPTIONS request to /evaluations/

$ [master]$ curl -v -H "Access-Control-Request-Method: POST" -H "Origin: https://some.staging.host.de" -X OPTIONS 127.0.0.1:3000/evaluations/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 3000 (#0)
> OPTIONS /evaluations/ HTTP/1.1
> Host: 127.0.0.1:3000
> User-Agent: curl/7.64.1
> Accept: */*
> Access-Control-Request-Method: POST
> Origin: https://some.staging.host.de
> 
< HTTP/1.1 200 OK
< Content-Type: text/plain
< Access-Control-Allow-Origin: https://some.staging.host.de
< Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT
< Access-Control-Expose-Headers: 
< Access-Control-Max-Age: 1728000
< Transfer-Encoding: chunked
< 
* Connection #0 to host 127.0.0.1 left intact
* Closing connection 0

but with the bump to 1.0.4 these are not returned any more:

$ [chore/update-rack-cors] curl -v -H "Access-Control-Request-Method: POST" -H "Origin: https://some.staging.host.de" -X OPTIONS 127.0.0.1:3000/evaluations/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 3000 (#0)
> OPTIONS /evaluations/ HTTP/1.1
> Host: 127.0.0.1:3000
> User-Agent: curl/7.64.1
> Accept: */*
> Access-Control-Request-Method: POST
> Origin: https://some.staging.host.de
> 
< HTTP/1.1 200 OK
< Transfer-Encoding: chunked
< 
* Connection #0 to host 127.0.0.1 left intact
* Closing connection 0

(NOTE: behaviour is the same for 127.0.0.1:3000/evaluations (without trailing slash) both in 1.0.1 and 1.0.4)

So somehow the matching of ressource paths seems to have changed.

For us it is also kind of intuitive that when defining a resource with /evaluations/* that this would include /evaluations/ and /evaluations as well. An comment on what the actual intended behaviour is would be helpful (and maybe worth to be added to the documentation).

Our current fix is to verbosly define following config:

    resource '/evaluations/*',
      headers: ['Origin', 'X-Requested-With', 'Content-Type', 'Accept', 'Authorization'],
      methods: %i[get post options put]

    resource '/evaluations',
      headers: ['Origin', 'X-Requested-With', 'Content-Type', 'Accept', 'Authorization'],
      methods: %i[get post options put]

Any comment is appreciated ;)

[cyu]

(document my rationale here because I'll forget)

I think you're right. It looks like Rack::Utils.clean_path_info removes the trailing slashes off paths, so...

• If /evaluations/* matches /evaluations/ which makes sense in my mind, then
• /evaluations/* should also match /evaluations since Rack::Utils.clean_path_info('/evaluations/') == '/evaluations'