How do I remove unused GET parameters from the URL?
How do I remove unused GET parameters from the URL?
am 20.01.2010 05:55:51 von Daevid Vincent
------=_NextPart_000_0267_01CA9949.C9CDF1E0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
I have an HTML form with a hundred or so elements on it, used for searching
a database.
When the user submits the form (via GET) the URL is loaded with ALL of
these fields, and many of them are not even actually used in the search
criteria.
https://mypse/dart2/ps_search.php?enter_date=2009-11-30&id_i ncident=&incide
nt_date=&incident_hh=0&incident_mm=0&id_urgency_level=0&prob lem_description
=&immediate_action=&unit_opened=&unit_authorized=&customer=& customer_contac
t=&customer_address=&customer_country=&id_location=0&passeng ers_onboard=&su
bmit=Search&part_number=&serial_number=&nomenclature=&manufa cture_date=&mod
_level=&id_lru_condition=&repair_history=&ac_type=&tail_numb er=&id_system_t
ype=&id_lru_location=0&circuit_breaker=&circuit_breaker_amps =&seat_number=&
seat_vendor=&seat_column_zone=&seat_zone=&tc_holder=&stc_hol der=&asr_mor=&i
mpounded=&id_authority=&id_region=&reported_by=&prepared_by= &preparer_locat
ion=&field_engineer=&id_attach_pictures=&id_attach_mlr=&id_a ttach_lopa=&cab
in_log=&parts_inspect=&id_organization=0&id_quality_engineer =0&car_number=&
close_date=&closed_by=&qa_comment=&id_priority=&id_action=0& id_incident_sta
tus=3&id_failure_type=&detail_status=&investigation_result=& osaka_action=&o
saka_request=&newvsrepeat=&related_incident=&unit_received_d ate=&unit_retur
ned_date=&tdr_to_pso_date=&tdr_date=&dcr_date=&dcr_reference _number=&ecr_da
te=&ecr_reference_number=&eco_date=&eco_reference_number=&se rvice_bulletin_
date=&sb_reference_number=&sil_issue_date=&sil_reference_num ber=&til_issue_
date=&til_reference_number=&customer_letter_issue_date=&suba ssembly=&rdm=&p
svector=&oemmanuf=&defective_part_1=&defective_part_2=&defec tive_part_3=&de
fective_part_4=
Is there some way via PHP/Apache Mod/Javascript to remove all the keys that
don't have any value in them and just distill this down to the
elements/keys that the user actually entered some input for? ie. defaulting
all the rest to 'blank'.
In PHP, this would look something like this:
foreach ($_GET as $k => $v) if ($v == '') unset($_GET[$k]);
The problem as I see it, is that this "magic" happens when the user hits
"Submit", so not sure PHP has any way to intercept at that point.
Javascript might be able to do something on the "onClick" event or
"onSubmit" I suspect. But this seems like something that someone should
have solved before and common enough that I would think Apache could handle
it transparently with a directive or module enabled so I don't have to code
some hack on every page.
I guess I could always redirect to some 'scrubber' page that strips them
out and redirects on to the refering page again, but that seems klunky.
BTW, I want to use GET so that the page can be bookmarked for future
searches of the same data (or modified easily with different dates, etc.),
so that's why I don't use POST.
------=_NextPart_000_0267_01CA9949.C9CDF1E0--
Re: How do I remove unused GET parameters from the URL?
am 20.01.2010 06:39:40 von Michael Peters
Daevid Vincent wrote:
*snip*
>
> The problem as I see it, is that this "magic" happens when the user hits
> "Submit", so not sure PHP has any way to intercept at that point.
> Javascript might be able to do something on the "onClick" event or
> "onSubmit" I suspect. But this seems like something that someone should
> have solved before and common enough that I would think Apache could handle
> it transparently with a directive or module enabled so I don't have to code
> some hack on every page.
>
> I guess I could always redirect to some 'scrubber' page that strips them
> out and redirects on to the refering page again, but that seems klunky.
>
> BTW, I want to use GET so that the page can be bookmarked for future
> searches of the same data (or modified easily with different dates, etc.),
> so that's why I don't use POST.
>
JavaScript is the only client side way I know of.
Use document.getelementbyid() and yank the unused nodes before submit.
server side, redirect - it shouldn't be that clunky.
Put in a hidden input that tells your action script to redirect to
itself without the unused get variables (and w/o the hidden input).
That's how I would do it personally (opposed to js).
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: How do I remove unused GET parameters from the URL?
am 20.01.2010 06:44:47 von Michael Peters
Daevid Vincent wrote:
>
> I guess I could always redirect to some 'scrubber' page that strips them
> out and redirects on to the refering page again, but that seems klunky.
>
> BTW, I want to use GET so that the page can be bookmarked for future
> searches of the same data (or modified easily with different dates, etc.),
> so that's why I don't use POST.
>
Another option is to use post in the form, and when your action page
receives post, it redirects to itself with the used variables as get.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: How do I remove unused GET parameters from the URL?
am 20.01.2010 12:32:54 von Rene Veerman
Michael, while i respect your choices, i think you should know that
jquery.com is pretty good at minimizing browser-incompatibility
headaches (and keeping js apps small), and the quircks that are left
are easy enough to learn about.
for things whereby
- the server needs to generate tons of HTML for a small(ish) dataset, or
- the client generates data (also to be translated to html) that the
server doesnt really need to know about (yet)
js can really take some stress off the server.
On Wed, Jan 20, 2010 at 9:31 AM, Michael A. Peters wrote:
> Rene Veerman wrote:
>>>
>>> That's how I would do it personally (opposed to js).
>>
>> wtf??! =A0js =3D less server stress :)
>>
>
> Many (myself included) surf with script blockers due to XSS and js is mor=
e
> difficult to thoroughly test because the implementation is done by browse=
rs
> without a good standards body for validating the the code.
>
> I've run into a couple situations where scripts worked perfectly for me i=
n
> Firefox, Opera, and Konq only to find out they failed in IE either becaus=
e
> IE did things differently (like attaching events) or something as stupid =
as
> IE not liking a space that the other browsers worked fine with.
>
> window.open(url,'Download
> Media','width=3D620,height=3D200,toolbar=3D0,location=3D0,di rectories=3D0=
,menubar=3D0,resizable=3D0');
>
> failed in IE because of the space between Download and Media, yet worked =
in
> all other browsers I tried, and didn't even give a warning in Firefox wit=
h
> the firebug plugin.
>
> Thus for me to implement a solution in JavaScript, the testing time goes =
way
> up because I have to test it in several versions of several different
> browsers.
>
> If I can do it server side, the only issues are CSS and appropriate
> fallbacks for bleeding edge tags (like the html5 tags), but I have to tes=
t
> for those anyway so doing it server side doesn't cost me any extra testin=
g
> time and doesn't end up with failures because I didn't test a particular
> version of a particular browser.
>
> Also, by minimizing the JavaScript, I minimize the amount of fallback
> testing I need to still keep viewers who have scripting disabled.
>
> Until there is some kind of a proper standard that the major browser vend=
ors
> adhere to with a validator I can check my JS against that will pretty muc=
h
> guarantee any validating JS works in the various browsers, I will continu=
e
> to do stuff server side as much as possible.
>
> I do use JavaScript for things like form validation (validated server sid=
e
> as well), upload progress, dynamic select menus where the content of one
> depends upon what was selected in another, etc. - but if I can do it serv=
er
> side I do, that's my philosophy. I understand it is a minority philosophy=
,
> but I get less headaches that way.
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: How do I remove unused GET parameters from the URL?
am 20.01.2010 14:26:49 von Ashley Sheridan
--=-fsRP8vVFnjA2SpomSd36
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
On Tue, 2010-01-19 at 20:55 -0800, Daevid Vincent wrote:
> I have an HTML form with a hundred or so elements on it, used for searching
> a database.
>
> When the user submits the form (via GET) the URL is loaded with ALL of
> these fields, and many of them are not even actually used in the search
> criteria.
>
> https://mypse/dart2/ps_search.php?enter_date=2009-11-30&id_i ncident=&incide
> nt_date=&incident_hh=0&incident_mm=0&id_urgency_level=0&prob lem_description
> =&immediate_action=&unit_opened=&unit_authorized=&customer=& customer_contac
> t=&customer_address=&customer_country=&id_location=0&passeng ers_onboard=&su
> bmit=Search&part_number=&serial_number=&nomenclature=&manufa cture_date=&mod
> _level=&id_lru_condition=&repair_history=&ac_type=&tail_numb er=&id_system_t
> ype=&id_lru_location=0&circuit_breaker=&circuit_breaker_amps =&seat_number=&
> seat_vendor=&seat_column_zone=&seat_zone=&tc_holder=&stc_hol der=&asr_mor=&i
> mpounded=&id_authority=&id_region=&reported_by=&prepared_by= &preparer_locat
> ion=&field_engineer=&id_attach_pictures=&id_attach_mlr=&id_a ttach_lopa=&cab
> in_log=&parts_inspect=&id_organization=0&id_quality_engineer =0&car_number=&
> close_date=&closed_by=&qa_comment=&id_priority=&id_action=0& id_incident_sta
> tus=3&id_failure_type=&detail_status=&investigation_result=& osaka_action=&o
> saka_request=&newvsrepeat=&related_incident=&unit_received_d ate=&unit_retur
> ned_date=&tdr_to_pso_date=&tdr_date=&dcr_date=&dcr_reference _number=&ecr_da
> te=&ecr_reference_number=&eco_date=&eco_reference_number=&se rvice_bulletin_
> date=&sb_reference_number=&sil_issue_date=&sil_reference_num ber=&til_issue_
> date=&til_reference_number=&customer_letter_issue_date=&suba ssembly=&rdm=&p
> svector=&oemmanuf=&defective_part_1=&defective_part_2=&defec tive_part_3=&de
> fective_part_4=
>
> Is there some way via PHP/Apache Mod/Javascript to remove all the keys that
> don't have any value in them and just distill this down to the
> elements/keys that the user actually entered some input for? ie. defaulting
> all the rest to 'blank'.
>
> In PHP, this would look something like this:
>
> foreach ($_GET as $k => $v) if ($v == '') unset($_GET[$k]);
>
> The problem as I see it, is that this "magic" happens when the user hits
> "Submit", so not sure PHP has any way to intercept at that point.
> Javascript might be able to do something on the "onClick" event or
> "onSubmit" I suspect. But this seems like something that someone should
> have solved before and common enough that I would think Apache could handle
> it transparently with a directive or module enabled so I don't have to code
> some hack on every page.
>
> I guess I could always redirect to some 'scrubber' page that strips them
> out and redirects on to the refering page again, but that seems klunky.
>
> BTW, I want to use GET so that the page can be bookmarked for future
> searches of the same data (or modified easily with different dates, etc.),
> so that's why I don't use POST.
You can't remove the empty fields server-side, as they never reach the
server. GET has a limit on the amount of data it may carry, which is
reduced the longer the base URL is. If you need to send large amounts of
data like that, you need to send it via POST. You can make minimal
changes to your PHP code to allow for this. If you use $_GET in your
PHP, swap it for $_REQUEST which contains both GET and POST data.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--=-fsRP8vVFnjA2SpomSd36--
Re: How do I remove unused GET parameters from the URL?
am 20.01.2010 19:30:18 von Michael Peters
Rene Veerman wrote:
> Michael, while i respect your choices, i think you should know that
> jquery.com is pretty good at minimizing browser-incompatibility
> headaches (and keeping js apps small), and the quircks that are left
> are easy enough to learn about.
>
> for things whereby
> - the server needs to generate tons of HTML for a small(ish) dataset, or
> - the client generates data (also to be translated to html) that the
> server doesnt really need to know about (yet)
>
> js can really take some stress off the server.
I also like to run any content that has user contributed data through a
server side filter that enforces Content Security Policy -
http://www.clfsrpm.net/xss/
That filter makes sure the content sent to the browser does not include
stuff that violates the defined CSP, and thus greatly reduces the risk
of malicious content that input filtering missed from reaching the end user.
Furthermore, when it does catch a violation, it reports the violating to
a log file notifying me of the problem.
The only way that works for content generated client side would be if
the user was running a browser that is CSP aware, and right now, they
just don't exist. Firefox has an experimental add-on for CSP but
virtually no one uses it.
Doing dynamic content server side allows me to run that content through
the enforcement filter server side thus catching policy violating
content before it is ever sent to the user.
That itself, btw, is probably the biggest stress on the server.
I understand prototype etc. is the "web 2.0" way but I really don't have
a high opinion of "Web 2.0". JavaScript, flash, etc. all have been used
far too often to do bad things.
Right now, if I don't block except for white listed web sites, I end up
with advertisements I don't care about expanding and covering the
content I do care about. Unfortunately the web is full of jerks who do
rude things with scripts, and people who do malicious things with scripts.
You wouldn't execute code that someone you don't know sent you an
e-mail, would you? I wouldn't, nor do I execute code someone I don't
know embeds in a web page.
I surf with script blockers (NoScript to be specific) and when I come
upon web sites that don't properly function, I'm a lot liklier to head
elsewhere than to enable scripting for that site. Since I surf that way,
I expect others do as well, doing things server side that can be done
server side allows users like me who block scripting to access the
content without compromising the security of our systems.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: How do I remove unused GET parameters from the URL?
am 20.01.2010 19:42:17 von Ashley Sheridan
--=-hsgwmuej0hV1ncm4lUM7
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
On Wed, 2010-01-20 at 10:30 -0800, Michael A. Peters wrote:
> Rene Veerman wrote:
> > Michael, while i respect your choices, i think you should know that
> > jquery.com is pretty good at minimizing browser-incompatibility
> > headaches (and keeping js apps small), and the quircks that are left
> > are easy enough to learn about.
> >
> > for things whereby
> > - the server needs to generate tons of HTML for a small(ish) dataset, or
> > - the client generates data (also to be translated to html) that the
> > server doesnt really need to know about (yet)
> >
> > js can really take some stress off the server.
>
> I also like to run any content that has user contributed data through a
> server side filter that enforces Content Security Policy -
>
> http://www.clfsrpm.net/xss/
>
> That filter makes sure the content sent to the browser does not include
> stuff that violates the defined CSP, and thus greatly reduces the risk
> of malicious content that input filtering missed from reaching the end user.
>
> Furthermore, when it does catch a violation, it reports the violating to
> a log file notifying me of the problem.
>
> The only way that works for content generated client side would be if
> the user was running a browser that is CSP aware, and right now, they
> just don't exist. Firefox has an experimental add-on for CSP but
> virtually no one uses it.
>
> Doing dynamic content server side allows me to run that content through
> the enforcement filter server side thus catching policy violating
> content before it is ever sent to the user.
>
> That itself, btw, is probably the biggest stress on the server.
>
> I understand prototype etc. is the "web 2.0" way but I really don't have
> a high opinion of "Web 2.0". JavaScript, flash, etc. all have been used
> far too often to do bad things.
>
> Right now, if I don't block except for white listed web sites, I end up
> with advertisements I don't care about expanding and covering the
> content I do care about. Unfortunately the web is full of jerks who do
> rude things with scripts, and people who do malicious things with scripts.
>
> You wouldn't execute code that someone you don't know sent you an
> e-mail, would you? I wouldn't, nor do I execute code someone I don't
> know embeds in a web page.
>
> I surf with script blockers (NoScript to be specific) and when I come
> upon web sites that don't properly function, I'm a lot liklier to head
> elsewhere than to enable scripting for that site. Since I surf that way,
> I expect others do as well, doing things server side that can be done
> server side allows users like me who block scripting to access the
> content without compromising the security of our systems.
>
It's for users like you that I keep saying to people that Javascript
shouldn't define functionality but enhance it. People will turn their
noses up at that attitude, but, like you said, some people get downright
nasty with the things they do online with their scripts.
I've not used that CSP thing you linked to before, it looks like it's
not for validating user input going *to* your server, but to sanitise
the downstream content from your server to the users browser. Validating
user input should prevent this as best as possible, as it shouldn't lead
to output from your script being used as part of an XSS attack. However,
the real worry is with ISP's that modify your pages before they are
output to the browser, as Canadian ISP Rogers has been found doing:
http://www.mattcutts.com/blog/confirmed-isp-modifies-google- home-page/
No PHP class will be able to prevent that, as the ISP is modifying the
content en route to its destination.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--=-hsgwmuej0hV1ncm4lUM7--
Re: How do I remove unused GET parameters from the URL?
am 20.01.2010 21:40:10 von Nathan Rixham
Daevid Vincent wrote:
> BTW, I want to use GET so that the page can be bookmarked for future
> searches of the same data (or modified easily with different dates, etc.),
> so that's why I don't use POST.
>
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.
possibly worth considering having a GET url which (p)re-populates the
form (rather than direct to the search results) so the search can be
easily modified before submitting it..?
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.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: How do I remove unused GET parameters from the URL?
am 20.01.2010 22:06:00 von Daevid Vincent
Comments inline below...
> -----Original Message-----
> From: Ashley Sheridan=20
>=20
> GET has a limit on the amount of data it may carry, which is
> reduced the longer the base URL is.=20
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-quer ystring/get/u=
rl
-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-maximu m-length-of-a=
n-
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=20
>=20
> 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.
>=20
> 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=20
> 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;=20
> if you use
> the api of bit.ly or suchlike you could do this serverside;=20
> 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ÏÐ=20
http://daevid.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: How do I remove unused GET parameters from the URL?
am 20.01.2010 22:48:42 von Ashley Sheridan
--=-vU85Ut3nyXxSg2z25nS9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, 2010-01-20 at 13:06 -0800, Daevid Vincent wrote:
> Comments inline below...
>=20
> > -----Original Message-----
> > From: Ashley Sheridan=20
> >=20
> > GET has a limit on the amount of data it may carry, which is
> > reduced the longer the base URL is.=20
>=20
> True, but for search parameters, it's IMHO best to use GET rather than PO=
ST
> so the page can be bookmarked.
>=20
> This used to be a concern "back in the day" with 255 bytes.
>=20
> http://classicasp.aspfaq.com/forms/what-is-the-limit-on-quer ystring/get/u=
rl
> -parameters.html
>=20
> Not so much anymore with most browsers supporting > 2000 characters:
>=20
> http://www.boutell.com/newfaq/misc/urllength.html
> http://support.microsoft.com/kb/208427
> http://stackoverflow.com/questions/417142/what-is-the-maximu m-length-of-a=
n-
> url
>=20
> 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.
>=20
> > -----Original Message-----
> > From: Nathan Rixham=20
> >=20
> > 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.
> >=20
> > 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=20
> > stripped); so maybe removal isn't the best option.
>=20
> Also a very valid point that I hadn't fully considered.
>=20
> > also you could just pass the url through to an url shrinker;=20
> > if you use
> > the api of bit.ly or suchlike you could do this serverside;=20
> > and reap the benefits of stats for each search too.
>=20
> 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 a=
nd
> this is a pretty interesting idea. Given your above observation, perhaps
> this *is* the solution to persue further...
>=20
> Way to think outside the box Nathan! :)
>=20
> ÃÃ5ÃÃ=20
> http://daevid.com
>=20
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: