Adding */* to Accept header seems to override other formats

[iangreenleaf]

This deals with a similar area as #4127, but the symptoms seem different enough that I thought it deserved its own bug. Hopefully I'm not wrong.

Make an endpoint that only responds to a particular MIME type, such as JSON:

  # GET /users.json
  def index
    respond_to do |format|
      format.json {
        @users = User.all
      }
    end
  end

We can make requests against this as long as we have something compatible in the Accept header:

$ curl -I -H"Accept: application/json" http://localhost:3001/users #=> HTTP/1.1 200 OK 
$ curl -I -H"Accept: application/json, foo/bar" http://localhost:3001/users #=> HTTP/1.1 200 OK
$ curl -I -H"Accept: application/json, foo/*" http://localhost:3001/users #=> HTTP/1.1 200 OK 
$ curl -I -H"Accept: application/*, foo/bar" http://localhost:3001/users #=> HTTP/1.1 200 OK 
$ curl -I -H"Accept: */*" http://localhost:3001/users #=> HTTP/1.1 200 OK 

But using */* in combination with a valid format somehow screws it up and causes it to try to force the format to text/html, which then fails when the action won't respond as such.

$ curl -I -H"Accept: application/json, */*" http://localhost:3001/users #=> HTTP/1.1 406 Not Acceptable 

Here's a simple Rails app that can reproduce the issue.. The users#index endpoint can be hit as in my above examples.

[sgrif]

I'm almost certain this is intentional. I looked into this a long while ago, and if you look hard enough you'll find previous discussions about this issue (sorry, I don't have a link) but it involves browsers not actually following the spec on properly specifying their Accept header, Safari in particular being problematic.

[pixeltrix]

Duplicate of #8987 - see there for discussion of why it happens