On Wed, 2010-01-20 at 13:06 -0800, Daevid Vincent wrote: > Comments inline below... > > > -----Original Message----- > > From: Ashley Sheridan > > > > GET has a limit on the amount of data it may carry, which is > > reduced the longer the base URL is. > > True, but for search parameters, it's IMHO best to use GET rather than POST > so the page can be bookmarked. > > This used to be a concern "back in the day" with 255 bytes. > > http://classicasp.aspfaq.com/forms/what-is-the-limit-on-querystring/get/url > -parameters.html > > Not so much anymore with most browsers supporting > 2000 characters: > > http://www.boutell.com/newfaq/misc/urllength.html > http://support.microsoft.com/kb/208427 > http://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-an- > url > > Re-writing it to handle $_REQUEST doesn't seem to solve much as the user > would still need to know the form element names and the actual form would > be either POST/GET. GET is the problem I have now. POST is a whole other > problem of not being able to bookmark. > > > -----Original Message----- > > From: Nathan Rixham > > > > to do as you say on the clientside you'd probably be best to write a > > short js script to build the get url from the form data; and on the > > serverside just take the klunky approach you mentioned. > > > > worth thinking about scenarios where a field is empty on the initial > > search though; but a user may want to modify it by entering in a value > > to a previously blank field (which would at this point be > > stripped); so maybe removal isn't the best option. > > Also a very valid point that I hadn't fully considered. > > > also you could just pass the url through to an url shrinker; > > if you use > > the api of bit.ly or suchlike you could do this serverside; > > and reap the benefits of stats for each search too. > > This is for an internal intranet site so I can't use an outside shrinker, > however I suspect the code to create my own shrinker isn't so difficult and > this is a pretty interesting idea. Given your above observation, perhaps > this *is* the solution to persue further... > > Way to think outside the box Nathan! :) > > ÐÆ5ÏÐ > http://daevid.com > What about sending the form via POST, but to a URL that includes some sort of session in the URL the form is sent to, for example: <form action="page.php?sid=gsslgugckjeglktjb" method="post"> Then your server script can reproduce the search from saved parameters stored under the sid value. This way, you retain the ability to bookmark the search, and use as many search parameters as you need, without worrying about going over the GET data limit no matter what browser the user has. Thanks, Ash http://www.ashleysheridan.co.uk
