Problem mit URL encoding 404er-Fehlern

[niffchen]

Hallo,

ich habe mal wieder eine Herausforderung, bei der ich gerade nicht so richtig weiter weiß.
Diesmal geht es um das URL-Encoding und damit verbundene 404er.

Alles dreht sich zum Beispiel um diese URL im Original:
http://www.rohstoffverarbeitender-betri ... ag/zubehör

In der Sitemap kommt die URL wie folgt vor:
http://www.rohstoffverarbeitender-betri ... beh%C3%B6r

Das macht für mich noch Sinn, wird doch der Umlaut anders dargestellt.
In den Webmaster-Tools von Google werde ich darauf gestossen, dass Google versucht diese URL aufzurufen, aber unter diesem Namen:
http://www.rohstoffverarbeitender-betri ... 25C3%25B6r

Da wird das % anscheinend auch noch codiert.
Wenn ich die letzte URL, wie von Google entnommen, aufrufe, dann bekomme ich eine Fehlerseite, wie ich sie für nicht vorhandene Seiten engestellt habe!

Wisst Ihr wie ich das umgehen kann, außer keine Umlaute zu benutzen?
Muss ich bei Serendipity etwas einstellen, damit er auch die letzte URL sauber bearbeiten und die passenden Seite anzeigen kann?

Gruß und vielen Dank,
Jens

[Timbalu]

Das ist halt 2x enkodiert worden. Einmal vom S9y Plugin und später noch einmal von Google.
Auf http://url-encoder.de/ kannst du das sehen, wenn du 2 mal dekodieren aufrufst.
Ob man Google anweisen kann die WMT ensprechend einzustellen, weiß ich nicht.

Google selbst empfiehlt die URL zur eigenen Sitemap kodiert (encoded) einzureichen. Folglich wird aus der unkodierten (decoded) URL “http://www.meinedomain.de/sitemap.xml” die kodierte (encoded) URL “http%3A%2F%2Fwww.meinedomain.de%2Fsitemap.xml”.

Und in deinem Beispiel das Tag zubehör zu zubeh%C3%B6r.

Du hast nun außerhalb dessen generell nur 2 Möglichkeiten. Entweder keine Umlauts in Tags, oder in https://github.com/s9y/additional_plugi ... p.php#L540 das

Code: Select all

urlencode($cur['tag'])

in ein

Code: Select all

$cur['tag']

zu verwandeln. Aber das bringt wahrscheinlich andere Probleme, da u.a. der/die Browser das unterstützen müsste(n).

Aber! Vielleicht müsste man einfach im freetag Plugin ein double urlencode einbauen...?
Das sollte eigentlich nicht schaden. Kannst du das mal testen?

Einfach nach
https://github.com/s9y/additional_plugi ... g.php#L722
ein

Code: Select all

$param = urldecode($param); // double decode for tag umlauts via google WMT

einfügen.

PS. Das ist jetzt noch nicht besonders ausgearbeitet. Die Ursache könnte eventuell auch noch woanders liegen.

[niffchen]

OK, kann ich mal testen.
Aber sollte diese encodete URL nicht erkannt und die korrekte URL angezeigt werden? Mich wundert es dass ich 404er bekommen, nur weil auch noch das "%" codiert wurde ...

Gruß,
Jens

[Timbalu]

Wird sie ja, wenn sie einfach encoded/decoded wurde. Siehe den zweiten deiner Links.
Der 404 header kommt, weil es diesen doppelt encodeten und nur 1x decodeten tag nicht gibt. Beim zweiten Link wird aber alles korrekt aufgelöst und es gibt einen 200 OK.
Mit dem doppelten decode sollte das dann auch mit dem dritten Link klappen.

[niffchen]

Ah darauf will der Mann hinaus, verstanden
Aber an sich wäre es ja schön, wenn Serendipity das von Haus aus machen würde

Das ist übrigens kein Google WMT Problem. Ich bekomme offizielle Crawling-Fehler reportet, weil Google die URLs entweder so indexiert und beim nächsten Crawlen nicht findet oder direkt das % codiert und due URL dann nicht aufrufbar ist. Google kann also alle meine Seiten mit der einfachen Codierung so nicht aufrufen. Bisher habe ich die alle via .htaccess gerade gezogen, was ich nun aber mal aufräumen wollte.

[Timbalu]

Laut meinen test ist der Einbau eines doppelten decodes im freetag plugin durchaus eine Lösung für das Problem mit diesen links. So Garvin, wenn er denn mal wieder Zeit findet, das auch so sieht und nichts besseres in petto hat (gerade auch was deinen Nachtrag angeht), wird ein update sicher nachgeschoben. (siehe auch pending request http://board.s9y.org/viewtopic.php?f=10 ... #p10440668)

[niffchen]

Ich habe eben auch die Zeit zum Testen gefunden und es funktioniert problemlos.
Im Moment ist das Problem für mich damit behoben.
Muss ich mir mal auf die Liste der Anpassungen schreiben, damit es nicht beim nächsten Update in Vergessenheit gerät

Danke für die Hilfe!

[garvinhicking]

Die Gefahr von mehreren urldecodes ist, dass man dann XSS untergejubelt kriegen kann. Das muss gut getestet werden damit keine Parameter übertragen werden die "böse" sind (<> " ' etc.)

LG
Garvin

[Timbalu]

Hmm. Das wollen wir ja auch nicht!
Es geht ja darum, dass irgendwer das % von %C3 noch einmal zusätzlich encoded, zu %25. Und das, weil dieser Jemand nicht versteht, dass %C3 zu %B6 gehört (ö) und nicht alleinstehend verwendet werden kann. (IMO)

Code: Select all

zubeh%C3%B6r
zubeh%25C3%25B6r

Das XSS sollte aber nicht vorkommen.
Denn jetzt schon ist für die allermeisten folgenden Ausgaben
ein array_map('htmlspecialchars', $param) oder single tag htmlspecialchars($param) im Anschluss vorgesehen.

Ich poste morgen mal eine Version, mit der diese doppelten decodes gesetzt sind und doppelt darauf geachtet wird, bösartige inserts allerorten auszufiltern. Außerdem wird dann das FR tags-als-liste ermöglicht.

[niffchen]

@Timbalu: Das klingt gut. Wenn Du die Version dann hast, würde ich das mal testen.
Danke dafür!

[Timbalu]

Bitte noch ein mal lesen:

> Sa Sep 27 - Ich poste morgen mal eine Version

Sollte also schon lange erhältlich sein.

[niffchen]

@Timbalu: Man muss auch an der richtigen Stelle nach der neuen Version suchen, dann klappt es auch mit dem PlugIn
Mein Fehler! Hat geklappt und funktioniert 1a!
Super und vielen vielen Dank für die Hilfe!

Gruß,
Jens