VuFind

Joel Norman added a comment - 18/Oct/08 9:29 PM Whoops! I opened another bug report Vufind -15 on this... Anyways, there is a fix in that report. Cheers!

Bill Dueber added a comment - 23/Oct/08 11:48 PM Just a note that changing from GET to POST requires changes in the templates, the AJAX calls (client and server side) for facets, and of course calls to solr in Solr.php.

Bill Dueber added a comment - 28/Oct/08 4:48 PM Enclosed is a patch against web/services/Search/ajax.js and AJAX.PHP that change the calls to get facets (getNarrowOptions) to use POST instead of GET.

Bill Dueber added a comment - 28/Oct/08 9:09 PM Oops. This patch is actually against current trunk (1139) instead of my local repo.

Wayne Graham added a comment - 11/Nov/08 3:06 PM Bill, I was just testing this patch out. Did you change the web/interface/themese/Search/advanced.tpl and web/services/Search/Home.php? Could you add a patch for these to?

Greg Pendlebury added a comment - 14/Oct/09 10:50 PM I can resolve this in the Search Object (VUFIND-134) . Ideally the use of saved searches will allow urls to still be copy/paste compatible after the convert to POST for the form. Most likely just have the advanced search screen 'reserve' a search ID before it is submitted, and update the search after submission.

Greg Pendlebury added a comment - 27/Oct/09 10:42 PM Off the top of my head there are three related issues here: 1) Facets (RESOLVED)... since facets no longer are called via AJAX. 2) Solr query (RESOLVED). Solr.php appears to handle POST fine, and I've just switched the search object to default submitting POST queries to solr. 3) Long urls for the user getting from the advanced screen to the results list. Discussed below. A) My tests this morning with three decent search groups resulted in a 385 character URL, translating into 6,000+ on the solr url (which isn't the issue). I wonder whether this is really an issue with a 2,000 (practical) character limit. B) IF we still need to resolve point 3 I've considered the advanced screen 'reserving' a search table row and redirecting via url to edit that search ID. Then submitting via post with an id in the URL (action attribute of the form). The search is still copy/pastable that way, which was really the only detraction from a simple POST conversion of the form. BUT for that complication there are still limits. We would have to default to saving searches for the url to persist by default, and we would have to default to 'public' saved searches to allow the url to be sent to another person.

Demian Katz added a comment - 29/Oct/09 9:14 AM - edited Here's another possible approach to the problem that reduces reliance on saved searches at the cost of adding an extra redirect to the advanced search process. 1.) Advanced search screen always uses POST, and includes a special hidden field that flags searches that are POSTed from it. 2.) Search processing code detects the "POSTed Advanced Search" flag and converts all POST fields (minus the special hidden flag) into GET parameters, building up a new URL. 3.) We can now measure the length of the GET version of the advanced search. If it is short enough, we can just redirect there. If it is too long, we can save the search object and redirect to the saved link. Bottom line is that we perform a POST and then intermediate code turns it into a GET. That's an extra step that may slow things down slightly, but I don't think it's likely to be noticed. We only resort to saved searches in what I expect to be a very rare case, and we have completely stable (not tied to database), copyable URLs the rest of the time. Does this make sense? I can put together a patch file as a demo if you like.

Greg Pendlebury added a comment - 08/Nov/09 8:40 PM - edited Sorry, I've been off the radar for a bit. I'm somewhat hesitant to leap into this as well, because I'm not convinced the ideas we both put forward are perfect (I prefer yours BTW Demian). They just seem too hacky, and sacrifice simplicity and performance for trivial technical gains. Should we perhaps leave it as GET and move the issue out of RC2 for later consideration? The test data I posted above would seem to indicate only very edge cases are still going to be an issue. EDIT: Perhaps ask some faculty librarians to even come up with a realistic example of a 2,000+ character search? Just to see how absurb a request it would take to break things (for IE users).