From: "Daevid Vincent" on
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_incident=&incide
nt_date=&incident_hh=0&incident_mm=0&id_urgency_level=0&problem_description
=&immediate_action=&unit_opened=&unit_authorized=&customer=&customer_contac
t=&customer_address=&customer_country=&id_location=0&passengers_onboard=&su
bmit=Search&part_number=&serial_number=&nomenclature=&manufacture_date=&mod
_level=&id_lru_condition=&repair_history=&ac_type=&tail_number=&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_holder=&asr_mor=&i
mpounded=&id_authority=&id_region=&reported_by=&prepared_by=&preparer_locat
ion=&field_engineer=&id_attach_pictures=&id_attach_mlr=&id_attach_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_date=&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=&service_bulletin_
date=&sb_reference_number=&sil_issue_date=&sil_reference_number=&til_issue_
date=&til_reference_number=&customer_letter_issue_date=&subassembly=&rdm=&p
svector=&oemmanuf=&defective_part_1=&defective_part_2=&defective_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.
From: "Michael A. Peters" on
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).
From: "Michael A. Peters" on
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.
From: Ashley Sheridan on
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_incident=&incide
> nt_date=&incident_hh=0&incident_mm=0&id_urgency_level=0&problem_description
> =&immediate_action=&unit_opened=&unit_authorized=&customer=&customer_contac
> t=&customer_address=&customer_country=&id_location=0&passengers_onboard=&su
> bmit=Search&part_number=&serial_number=&nomenclature=&manufacture_date=&mod
> _level=&id_lru_condition=&repair_history=&ac_type=&tail_number=&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_holder=&asr_mor=&i
> mpounded=&id_authority=&id_region=&reported_by=&prepared_by=&preparer_locat
> ion=&field_engineer=&id_attach_pictures=&id_attach_mlr=&id_attach_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_date=&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=&service_bulletin_
> date=&sb_reference_number=&sil_issue_date=&sil_reference_number=&til_issue_
> date=&til_reference_number=&customer_letter_issue_date=&subassembly=&rdm=&p
> svector=&oemmanuf=&defective_part_1=&defective_part_2=&defective_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


From: "Michael A. Peters" on
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.