search filters should be request.method agnostic

[whatisgalen]

currently some search-filters are hard-coded to look for the paramater/query-string (or other query args) on a GET request body. Instead, they should use the search request object created in the search-view which looks for either a GET or a POST request

[bferguso]

I think this brings up a larger issue that I've been mulling over for a while, and will likely start to come up with the addition of the filter by feature functionality. I think we need to find a strategy to handle filters that exceed the maximum URL length. Filter requests are all currently submitted as GETs, which is convenient because the filter can easily be bookmarked / shared. However once the filter exceeds the maximum URL length (which varies with the browser) then the calls start to fail.

I've started an implementation that uses a POST if the URL length is exceeded, however it means that the filter can no longer be saved or shared. I'm wondering if we should have a discussion as a group to agree to an overall strategy to handle this.

[whatisgalen]

@bferguso in the case of a search url being used in the arches /search UI, it would be pretty straightforward to dynamically set the request to POST regardless of whether it was a "saved-search" or an ad hoc one. For search requests sent from somewhere else on the backend I think it's probably more complicated but I'm guessing there's a path

[bferguso]

@whatisgalen - Yes - it's pretty straight forward, however just changing the request type from GET to POST breaks the current functionality that you can just bookmark/share any arbitrary ad-hoc search as you lose the parameters when they're stored in the request body. You also lose the search context if you do a simple page refresh.

There's also some coordination necessary as the parameters are expected to be URL encoded in a number of places (general search, advanced search, etc).

[whatisgalen]

@bferguso you could just modify this code in your own search-view to dynamically set POST vs GET based on json string char limit. This code gets executed for in-app searches as well as when saved-searches get loaded. I'm not seeing a blocker or a loss of functionality in saved-searches or parameters...maybe I'm missing something?

[whatisgalen]

@bferguso sorry I think I understand now what you were alluding to -- requests that are too long for GET and thus must be handled as POST cannot store all their query parameters in the url, meaning you can't just copy and paste that url into a saved search. Yes -- you are totally right.

I think a real solution to this problem might look like this for example:
A user logged in as admin (or some other high-level credential) can click a button in search "Save this Search" that copies the json object into an appropriate field on the "saved search" model, that way you don't need to worry about the url fully representing the search. (edit: just made #11592)