I know. I'm talking about parameters that aren't handled in `filter.py`. If I just inserted

    else:
        raise InvalidQuery("`{}` is not a valid query string parameter. Did you mean to add an `i:`, `e:`, or `k:` prefix?".format(q))

here, then it would mean the user could never access more than the first `settings.REST_FRAMEWORK['PAGINATE_BY']` records via the API, because "'page' is not a valid query string parameter". Obviously I could add an `elif q in UNHANDLED_PARAMS` with `UNHANDLED_PARAMS` holding a list of parameters we want to pass through, or even `elif q in map(lambda field: field.name, queryset.model._meta.fields) and q not in UNHANDLED_PARAMS`, but the fundamental problem with trying to police the parameters in a GET request is that some or all of them may be handled by components which currently exist, but which I don't fully understand, or by components that don't yet exist but which may require additional query parameters. If that were the case, this could potentially induce a lot of user- and dev-hostile behavior by telling them that a perfectly valid query is not or by making a future dev spend a lot of time trying to figure out why they can't pass a custom query param to an API view.