Hallo portseven,
die Semantik der HTTP-Verben GET und POST ist so, dass ein GET idempotent ist - d.h. ein mehrfacher GET auf die gleiche URL liefert immer das gleiche Ergebnis und ändert nichts an den gespeicherten Daten des Servers (abgesehen von Session-DB und Logs). Ein POST ist es dagegen nicht, er sendet Daten mit der Absicht, die auf dem Server gehaltenen Daten zu verändern.
Die Grenze mag ab und zu fließend sein, vor allem dann, wenn ein GET eine Momentaufnahme einer veränderlichen Datenbasis liefert (Aktienkurse), aber die Grundidee bleibt: Einen GET kann ich gefahrlos mehrfach ausführen, einen POST nicht.
Deswegen ist ein POST für dein Formular das falsche HTTP Verb, du änderst nichts, du sendest nur Filterwerte. Gib deinem form-Element das Attribut method="GET" und das Problem ist gelöst.
Aber Vorsicht: Das ist kein Allheilmittel. Zum einen wird durch dieses Verfahren die Datenübertragung an den Server geändert - die Parameter stehen nun in $_GET statt $_POST (weswegen Du sie besser aus $_REQUEST ausliest, dieses Superglobal fasst $_GET, $_POST und $_COOKIE zusammen). Zum anderen steht der Parameter nun sichtbar in der URL der Folgeseite - was aber in deinem Fall überhaupt kein Problem ist - eher ein Vorteil, weil man das Filterergebnis nun als Favorit speichern kann.
UND DRITTENS: Wenn Du auf Grund der Formulareingabe Updates in deiner Datenbank machst, dann ist ein erneuter Post tatsächlich kritisch und die Browserwarnung erfolgt aus gutem Grund. Dann sind die von Matthias verlinkten Verfahren anzuwenden, um dem Anwender zumindest eine kleine Chance zu lassen.
Ich habe es noch nicht ausprobiert; aber eventuell hat man mit dem History-API in JavaScript eine Chance, beim Klick auf Zurück den POST-Request zu überspringen.
Rolf
sumpsi - posui - clusi