HTTP Digest Authentication Bug?

Using Rails 3.1 and protecting some controller actions with HTTP
digest authentication. Some actions accept filter parameters from the
query string, and I have a button to “clear all filters”. This ‘reset’
effectively sets the query string to empty, but leaves the ‘?’ on the
URI. (1)

In Chrome, this causes the HTTP authentication to fail, while Firefox
silently removes the trailing ‘?’ and continues.

Some code examples follow, but I’m not familiar enough with the HTTP
specs to say if this is a bug in
ActionController::HttpAuthentication::Digest#validate_digest_response
or if the bug lies in Rack::Request#fullpath.

Here’s the gist of my controller

class SecureController
before_filter :authenticate!

def secret
# do some secure stuff
end

def authenticate!
authenticate_or_request_with_http_digest(“my_realm”) do |username|
USERS[username] # assume this is a username/digest hash defined
elsewhere
end
end

end

STEPS TO REPRODUCE:

navigate to http://localhost:3000/secure/secret
=> prompted for username and password

enter valid user credentials
=> access granted, page renders

filter data with a query, e.g.
http://localhost:3000/secure/secret?foo=bar
=> filtered data is returned

reset filter, e.g. http://localhost:3000/secure/secret? (2)
=> authentication fails, even with valid username/password

In Chrome, the filter reset leaves the URL with a trailing ‘?’. In
FireFox, the ‘?’ is removed. However, if I manually type in the
address http://localhost:3000/secure/secret? in FireFox, the
authentication failure is replicated.

Actually, the filters and button are all generated automatically with
Active Admin…

The code to reset the filters is actually JavaScript and is as
follows:

$(“.clear_filters_btn”).click(function(){
window.location.search = “”;
return false;
});

NB: I have also reported this as a bug on the Rails Github page: