: It's for an optimization. If the keyword is 'match all docs', I want to : remove a custom PostFilter from the query and change the sort parameters : (so the app doesn't have to do it). It looks like the responseHeader is : displaying the 'originalParams', which are immutable.
that is in fact the point of including the params in the header - to make it clear what exatly the request handler got as input. "echoParams" can be used to control wether you get "all" the params (including those added as defaults/appens in configuration) or just the "explicit" params included in the request -- but there's no way for a QParserPlugin to change what the raw query param strings are -- the query it produces might not even have a meaningful toString. the params in the header are there for the very explicit reason of showing you exactly what input was used to produce this request -- if plugins could change them, they would be meaningless since the modified params might not produce the same request. if you want to have a custom plugin that applies business logic to hcnage the behavior internally and reports back info for hte client to use in future requests, i would suggest doing that as a SearchComponent and inclding your own section in the response with details about what the client should do moving forward. (for example: i had a serach component once upon a time that applied QueryElevationComponent type checking against the query string & filters, and based on what it found would set the sort & add some filters unless an explicit sort / filter params were provided by the client -- the sort & filters that were added were included along with some additional metadat about what "rule" was matched in a new section of the response.) -Hoss http://www.lucidworks.com/
