Query as URL Path parameter breaks BISAC searches not contained in quotations

[mswinehart]

Regarding Eli's service alert email, relevant description below:

When a patron searches any variation of "Kids Book / Readers" or "Kids/ Books/ Reader" because they are trying to emulate the call number annotation search, a "The requested page could not be found." message shows up. LINK

Since the query is passed as a path parameter rather than a query parameter, this query never hits search code. Line 9 in the route file.

Changing this from a path param to a query param would probably require a lot of changed links. Worth discussing whether there is some additional routing logic to act on the third path layer under /search/ paths that we could place on the nginx level or as a route middleware.

[taleon]

I think we just need to ensure slashes are properly removed on the frontend JS and that should solve any issues here. Search can handle queries of the callnum without slashes and get a match,. @nickfreese could you take a look while you're looking at the 'keep all filters' toggle?

[taleon]

As a follow-up from dev yesterday, we could also do url encoding / decoding to be safe, but either approach should solve this issue.

[mswinehart]

@taleon

As I understand it, path params are not recognized by proxy_pass in the same way as query params, which is why search is usually done through query params. I think we'll still need to make some nginx changes even if we encode and decode the search query.

You can see this problem in action if you manually encode the forward slash in the URL: https://aadl.org/search/catalog/kids%20book%20%2F%20nonfiction

Somewhere (probably by nginx), %2F is decoded and spit back out as the forward slash as you can see in the search box. But in the url, it's still %2F.

I am not an nginx expert, so this might not be a big deal. @eby, can you shed any light here?

Also, we could just strip it as you suggested. Only downside there is just patron confusion.