Zusatzfrage: Kodierung, Query Strings und anderes ...

[ChrisB]

Hi,

Etwas unsicherer bin ich mir schon bei der Suche. Ich dachte bisher an etwas wie:
Suchseite: http://example.com/Search:
Ergebnisseite: http://example.com/Search(result?):CSS+HTML+Usability

Ich würde die Suchseite selber vielleicht nur
http://example.com/Search
nennen - das wäre analog dazu, unter /search.php nur das Suchformular auszuliefern, und unter
http://example.com/Search:Suchbegriff
dann die Ergebnisse zu diesem Suchbegriff, analog zu /search.php?query=Suchbegriff

Ein weiterer Punkt, der mir Kopfzerbrechen bereitet, ist die Sache mit dem Query String. Was mir sehr plausibel erscheint ist, dass es keine schlechte Idee ist, einen vorhandenen QS auf die enthaltenen Variablen zu prüfen und nur die durchzulassen, die als "erlaubt" hinterlegt sind. Auch könnte man darauf achten, dass bspw. nur die benötigten Variablen, d.h. die mit einem Wert, und stets in gleicher Reihenfolge sortiert im QS vorkommen.
Frage: Lohnt sich der Aufwand?

Weiss ich nicht.
Das Querystring-Parameter i.a.R. keine bestimmte Reihenfolge voraussetzen, ist generell erst mal ein Vorteil, den man durch Nutzung von mod_rewrite für "sprechendere" URLs sowieso erst mal zu nichte macht.

Bisher weiß ich noch gar nicht, ob ich überhaupt eine Seite haben werde, die per GET Daten versendet.

Tritt bei mir auch mehr und mehr in den Hintergrund - kommen eigentlich so gut wie nur noch bei AJAX-Requests zu Zuge, wo mich "schöne" URLs nicht so interessieren (müssen).

Andererseits könnte man so bspw. aber auch häufig vorkommende Suchanfragen cachen (vorausgesetzt natürlich, die Suchbegriffe und -kriterien sind exakt gleich).

Ob du nun /Search:Suchbegriff oder ?search.php?query=Suchbegriff cachen lässt, macht doch keinen Unterschied?

Und dann ist da noch das leidige Thema mit der "Besucher-Identifizierung/ -wiedererkennung". Denn ich würde dem User bspw. verschiedene Layouts (zumindest 2) anbieten wollen. Blöd nur, wenn der dann keine Kekse akzeptiert. Dann hätte ich in jedem Request die schei.. Session-ID. Oder gibt es für dieses Problem noch eine andere Lösung? Oder soll ich diesen Usern dann mitteilen, dass Cookies zwingend erforderlich sind für diese "Komfort-Funktion"?

Würde ich machen, ja.
Zwei verschiedenen Layouts ändern an den Daten selber nichts - also sehe ich auch keinen Grund, diese unter zwei verschiedenen Adressen anzubieten.

Jetzt nochmal kurz zurück zu dem Thema "Kontextwechsel erkennen und behandeln".
Wenn ich den Request in meinem PHP-Script verarbeite, muss ich dann auch irgendetwas de-/codieren, oder kann ich einen evt. vorhandenen QS einfach so "abschneiden" und wieder "anhängen"?

Die übliche kontextgerechte Behandlung wirst du natürlich durchführen - sonst hast du genauso wie mit PATH_INFO ein XSS-Problem, wenn du das, was der Client dir schickt, einfach durchreichst.

MfG ChrisB