A while ago I wrote Websites should not accept random parameters in requests, arguing that your web server or application should not accept query parameters that it doesn't expect. Recently there was a comment there that argued:

Postel's law does apply in the case. Consider the aspect of client and server versioning. Moreover, links may be recorded and followed at a later date. Your proposal of not serving a page with unexpected URLs will break links as soon as the server is modified.

I feel that this incorrectly merges the two difference cases of query parameters that you once used but no longer do and query parameters that you never used at all.

Query parameters that you've used in the past are a case of Cool URIs don't change. Any time you consider changing URLs, you should be making a conscious and deliberate decision. Ideally you'll carefully evaluate what URLs you want to stay and what URLs you want to stop working. And yes, sometimes I think that the right decision is to remove old URLs, because cool URLs are hard.

While it's tempting to 'support' old query parameters by accepting them and then ignoring them, I think that this is often a mistake. Mapping old URLs to new results is not necessarily doing anyone any favours; you really do need to return the same sort of thing that people are expecting. You can do a certain amount of remapping, but something like turning an Atom syndication feed into an HTML page is not actually any better than removing the URL entirely and returning a 404 result. If you want to really continue supporting the query parameters, you can't necessarily ignore them; you may well need to generate some redirects to the appropriate new versions of the pages.

Or in short: you don't want to just serve up any old page in response to old URLs, you want to serve up a useful result for the people who are using those old URLs.

(And if you can't serve up a useful result, the last thing you want to do is preserve the URL as something useful. Either return a 404 or serve up a redirect to some URL that you actually want people to use now.)

For query parameters that you have never used, the logic of my original argument applies in full force. You have no idea what effect or result the client expects to get from the query parameter, so robustness argues that you should not guess. That you might use some query arguments in the future is a weak argument; why is the client generating them now? The time to add support for them is when you actually use them (either in URLs you generate on the server or in a version of software that you push to clients).