On more than one occasion, people here have posted a link to a search that they did. (E.g. boards (dot) straightdope (dot) com/search.php?searchid=######) The result being that they can see the results okay, but others who click the link get an error message.
Is this because guests and unregistered folks can’t search?
If this is the reason why the search engine does that, then would it be difficult to change the board settings so that all Charter Members can access a search that another Charter Member has done and posted the link to?
The reason is that the URLs are not static, and expire. It would cost a huge amount in resources to make sure that you see the same results as someone else did at some other time. The best you can do is dig their search query out of the URL they posted and search again.
I don’t think it’s lame. When the search parameters were in the URL, you could manually change the URL to override some search limitations, like the max number of results returned (I think). This would slow systems down. I’m guessing this was one of the reasons for the change, and if so, it was sufficient.
That is a very not-creative solution…what are you trying to debate. The internet depends on hyperlinks to keep working. Creating hyperlinks that expire without even including the original search queries is ridiculous. Aside from that, there is mod_rewrite. There is no need to include /all/ of the search parameters in the URL.
At the risk of imparting information that somebody might think can be misused, I will point out that you can examine the search form page, and figure out the right arguments to construct a URL. Simply tack the POST’ed fields on the URL, as if the form was a GET instead[sup]1[/sup]. I’ve maintained bookmarks for form based page results on various sites this way, including canned searches on this site. I’ve often wondered why browsers don’t provide you with a mechanism for constructing a remembered POST as a bookmark in the first place.
A downside is that you may have to go through the process again to update your URL when there’s a new release and the form is redesigned.
Using such a bookmark shouldn’t be any more of a drain on the server than simply typing it in as often as you use the bookmark. Of course, maybe the convenience of the bookmark causes you to invoke the damned search more often than you should, or you’ve been nasty and allowed your browser to continually check it for updates, if it has such a feature. And it probably WOULD cause a hit to publish such a URL in a heavily read posting, causing the search to get redone over and over again by each user following the link.
(There bulletin board software could recognize what searches are actually cached, and simply return an already open one, if applicable, but something tells me it doesn’t do this. They likely wouldn’t have expected that optimization to buy them anything.)
[sup]1[/sup] - many application frameworks make both POST’ed and decoded URL arguments available to the programmer through the same API, generally resulting in applications that will behave the same whether a request was POST’ed to them or passed through URL arguments. This is certainly true of the J2EE framework I have the most experience with. If you wanted to, you could figure out whether a parameter came to you via the URL or not, but you would have to do extra work to do so.