It's not easy to use the proposed interface for query parameters. #2053
Description
# Returns the data received in the query string.
def GET
if get_header(RACK_REQUEST_QUERY_STRING) == query_string
if query_hash = get_header(RACK_REQUEST_QUERY_HASH)
return query_hash
end
end
set_header(RACK_REQUEST_QUERY_HASH, expand_params(query_param_list))
end
def query_param_list
if get_header(RACK_REQUEST_QUERY_STRING) == query_string
get_header(RACK_REQUEST_QUERY_PAIRS)
else
query_pairs = split_query(query_string, '&')
set_header RACK_REQUEST_QUERY_STRING, query_string
set_header RACK_REQUEST_QUERY_HASH, nil
set_header(RACK_REQUEST_QUERY_PAIRS, query_pairs)
end
end
Rails sub-classes this, and calls super in def GET.
Even if a sub-class overrides expand_params, it's cached into the same key.
Therefore, the previous call to Rack::Request#GET caches the value of expand_params, and the later invocation of MyCustomRequest#GET may reuse the same cache even with different expand_params behaviour.
Additionally, setting set_header RACK_REQUEST_QUERY_HASH, nil won't trigger if query_hash = get_header(RACK_REQUEST_QUERY_HASH) later, so I'm not sure if that's supposed to be cached. I suggest we keep manipulation of RACK_REQUEST_QUERY_HASH out of query_param_list.
Rails PR: rails/rails#47652
cc @matthewd