Should top-level self links include unsupported query parameters?

As discussed in

and

the top level “self” link should contain the the link that generated the current response document.

But what about unsupported parameters?

Let´s say there is an optional custom parameter which is not supported anymore but a client sends that parameter in the request.

GET /myResource?optionalLegacyParam=true

How should the server handle that situation?

  • should the server ignore the parameter but include it in the top level “self” link?
    I mean - it´s part of the URL that generated the response. Although it was not used bythe server.
  • should the server ignore the parameter and exclude it in the top level “self” link?
    That could be confusing for the client if the “self” link does not match the requested URL and may violate the principle of least suprise.
  • should the server respond with 400 Bad Request?
    On the one hand, this would violate the robustness principle (be liberal in what you accept)
    On the one hand the specification states that unsupported query parameters should be rejected (at least those which don´t follow the naming conventions?)

What do you recommend?