Fehler bei der Suche mit Slash

[bfalkenstein]

(OPUS 4.8.0.5)

Gibt man in der Suche einen String mit Slash ein (z.B. eine DOI wie 10.3390/brainsci13071001), so gibt es zwar Treffer, aber diese beziehen sich nur auf den ersten Teilstring vor dem Slash (also 10.3390).

Beispiel: https://example.com/solrsearch/index/search/start/0/rows/10/sortfield/score/sortorder/desc/searchtype/simple/query/10.3390%2Fbrainsci13071001

Klickt man dann einen der Treffer an, gibt es die Fehlermeldung

Fehler: Umleitungsfehler
Beim Verbinden mit example.com trat ein Fehler auf.
Dieses Problem kann manchmal auftreten, wenn Cookies deaktiviert oder abgelehnt werden.

Beispiel: https://example.com/frontdoor/index/index/start/0/rows/10/sortfield/score/sortorder/desc/searchtype/simple/query/10.3390/brainsci13071001//docId/10568

Die Ursache scheint zu sein, dass der Slash in der Query nicht korrekt escaped wird.

[j3nsch]

Danke für die Meldung. Eine Idee, ob das früher funktioniert hat?

Auf meinem lokalen Entwicklungssystem bekomme ich nicht einmal Suchergebnisse wenn ich ein Slash im Suchfeld verwende. Ich werde erst einmal Tests hinzufügen. Im Prinzip sind es zwei Probleme, einmal die Suche mit Slash und dann die Generierung der Treffer URLs.

[bfalkenstein]

In 4.7.1.2 funktioniert beides, also sowohl die Suche (d.h. es wird der komplette String gefunden, nicht nur der Teil vor dem Slash), als auch der Link von der Trefferliste zum Einzeltreffer.

[j3nsch]

Danke. In der Demo-Instanz, OPUS 4.8.0.4, scheint es auch zu funktionieren. Ich habe mit einem kürzeren String "10/20" getestet, aber das sollte ja keinen Unterschied machen.

https://opus4mig.kobv.de/opus4-demo

Die Demo-Instanz läuft mit PHP 7.1 und Solr 7. Vielleicht sind das Faktoren bei dem Problem. Mein System läuft mit PHP 8.1 und Solr 9.5.

[j3nsch]

Mit der PHP Version wechselt auch das opus4-search Package. Für PHP wurde Solarium 6 anstelle von 3 verwendet, weil die alte Version nicht mehr kompatibel war. Dafür mussten Änderungen im Search-Code vorgenommen werden bzw. evtl. verhält sich Solarium etwas anders. Anscheinend gibt es da weitere Testlücken.

[j3nsch]

Tests müssen in der Application, als Integrationstests, und in opus4-search als Unit Tests hinzugefügt werden. Die einen Tests stellen sicher, dass die Suche im Kontext der Application funktioniert, die anderen, dass einem Probleme nicht erst in der Application auffallen.

[j3nsch]

Ich konnte das Problem in der Suche noch nicht in Tests reproduzieren. Meine Unit Tests laufen lokal durch, aber auf dem gleichen System, mit der gleichen Instanz, gibt es im Browser (Firefox, Chromium) Fehlermeldungen. Bei den Tests werden die Requests direkt in das Zend-Framework injiziert. Das heißt der Browser und Apache2 fehlen in der Verarbeitung. Vielleicht komme ich mit Live-Debugging der Requests vom Browser im Server weiter.

[bfalkenstein]

Nachtrag: Wie haben aktuell eine andere Fehlermeldung von einem Kunden betr. Slash in der Suche, allerdings betrifft dies die Version 4.7.1.2:

Sucht man einen Titel, der die Zeichenfolge " / " (Leerzeichen Slash Leerzeichen) enthält, wirft OPUS den Fehler
"Anwendungsfehler
Die Suche konnte aufgrund eines Fehlers nicht ausgeführt werden."

Bei Titeln, die einen Slash ohne Leerzeichen davor und dahinter enthalten, funktioniert die Suche dagegen korrekt.

Vielleicht hängt dieser Fehler mit dem eigentlichen Issue zusammen?

[j3nsch]

FYI @stconradr, @vgerlach

@bfalkenstein Okay, auf meiner Liste sind das dann vier verschiedene Probleme, die alle mit Slash zusammenhängen, die aber durchaus unterschiedliche Ursachen haben können.

Auf meinem System komme ich gar nicht erst zu den Suchergebnissen, wenn ich versuche eine Suche mit Slash auszuführen. Ich habe versucht es zu debuggen, aber da läuft etwas schief, bevor der Request im OPUS 4 Code für die Suche ankommt. Es ist noch nicht klar, wo genau die Verarbeitung abbricht, in Apache2 oder in Zend. Ich teste jetzt erst einmal auf meinem zweiten Entwicklungssystem, um zu schauen, ob das Verhalten dort identisch ist.

[j3nsch]

@bfalkenstein Ich habe gerade keine Instanz mit OPUS 4.7.1.2, mit der ich experimentieren kann und da es in der aktuellen Version noch Probleme gibt, lohnt sich der Aufwand im Augenblick nicht. In der Demo-Instanz kommt bei einer Suchanfrage mit einem Leerzeichen vor einem Slash eine Fehlermeldung. Das ist unabhängig davon, ob ein Titel mit Slash existiert oder nicht. Stimmt das für die ältere Version auch? Tritt das Problem auf, weil mit Slash und Leerzeichen gesucht wird, oder wenn ein entsprechender Titel gefunden wird?

[j3nsch]

Mein lokales Problem mit %2f könnte mit folgender Option zusammenhängen. Das scheint im Hosting andere konfiguriert zu sein. Wenn ja bitte kurz kommentieren, @stconrad, @zibboehmert. Vielleicht sollte das in die Dokumentation aufgenommen werden.

https://httpd.apache.org/docs/2.2/en/mod/core.html#allowencodedslashes

UPDATE: Ich habe gerade gesehen, dass wir AllowEncodedSlashes in unser apache2.conf für OPUS 4 haben. Lokal scheint Apache2 aber trotzdem keine URLs mit %2f annehmen zu wollen. Das macht es mir gerade etwas schwer mit den anderen Problemen weiter zu kommen. In den Unit Tests, bei denen Browser und Apache2 umgangen werden, funktioniert bislang alles wie erwartet.

[zibboehmert]

Auf Prod und Mig ist AllowEncodedSlashes On gesetzt. Dürfte aus alten Versionen übernommen worden sein. Wenn es nicht erforderlich ist, kann es gern geändert werden.

[j3nsch]

@zibboehmert Wir haben Suchanfrage in denen Slashes auftauchen, z.B. bei DOIs. Encoded Slashes sind also notwendig, aber man könnte NoDecode probieren, damit der Query-String erst im OPUS 4 Code dekodiert wird. Das ist aber nicht das akute Problem. Wir haben mehrere Fehler bei der Suche mit Slashes. Eine Suche mit Slash scheint aber prinzipiell in der Demo Instanz möglich zu sein.

https://opus4mig.kobv.de/opus4-demo/home

Auf meinen Entwicklungsmaschinen ist sie das nicht und solange ich das Problem nicht gelöst habe, kann ich auch die anderen Probleme nicht weiter diagnostizieren. Ich verwende die Standard Apache2 Konfiguration für OPUS 4 und habe sonst nicht am Apache2 geschraubt auf meinen Ubuntu 22.04 Systemen. Momentan bekomme ich Apache2 nicht dazu URLs mit %2f zu akzeptieren.

[stconradr]

Habe mit der 4.8.1, solr961, und ubuntu 22 getestet.

z.B. der String "test/slash" im Feld Abstract bei drei unterschiedlichen Dokumenten wurde 3x gefunden.
Der String "/test/slash im Feld Title wurde ebenfalls bei der Suche "test/slash" gefunden.

Der String der DOI "10.1007/s12532-023-00247-3" wurde nur einmal gefunden, war aber zwei mal vorhanden, einmal in einem Dokument im DOI-Feld und einmal in einem Dokument im Abstract und Title.

[CAWinter]

Danke für Eure Hinweise!
Es hat sich herausgestellt, dass der Proxy das Problem ist und dass das Problem auch schon bei Proxies mit Opus Version 4.7.x mit PHP 7 und Solr 7 auftratt.

AllowEncodedSlashes sind bei uns immer auf On (Proxy und Backend), sonst kommt es zu einem 404-Fehler, da dann die Url nicht richtig erkannt wird.

Mit der Proxy-Konfiguration:
ProxyPass /opus https://backend.bsz-bw.de/opus nocanon
kommen auch die Encoded-Url korrekt im Backend an, zumindest im Fall der Doi-Suche.

Zu nocanon:
The optional nocanon keyword suppresses this and passes the URL path "raw" to the backend.

Das hat aber eventuell andere Nachteile.

[j3nsch]

@CAWinter Danke, das ist gut zu wissen. Löst das jetzt alle von Euch gemeldeten Probleme? Es löst leider nicht mein lokales Problem, bei dem Suchen mit Slash gar nicht bei OPUS 4 ankommen, trotz AllowEncodedSlashes On was ja zur Standard-Konfiguration für OPUS 4 gehört.

[CAWinter]

Unser Problem hat das momentan gelöst.

[bfalkenstein]

Das zweite Problem (Leerzeichen Slash Leerzeichen) ist leider damit noch nicht gelöst. Das trat ja in einer 4.7.1.2 ohne Proxy auf. In einer 4.8.0.5. mit Proxy gibt es den Fehler ebenso, jetzt mit dem Text
"Anwendungsfehler
Die angegebene Suchanfrage wird nicht unterstützt."

Das hat also anscheinend nichts mit dem Proxy zu tun.

[j3nsch]

@bfalkenstein Danke, das wollte ich wissen.

Mein lokales Problem, bei der Suche mit Slash überhaupt, ist gelöst. Jetzt kann es mit dem Rest weitergehen. Die Anweisung AllowEncodedSlashes on musste in die Konfiguration des VirtualHost gehen. Ich weiß nicht, ob das schon immer so war, oder ob sich irgendwann etwas geändert hat, aber der Eintrag in der OPUS 4 Apache2 Konfiguration reicht anscheinend nicht.

[j3nsch]

@bfalkenstein Ein Leerzeichen nach dem Slash scheint egal zu sein. Der Anwendungsfehler kommt wenn vor dem Slash ein Leerzeichen ist. Wenn man den Suchstring in Quotes fasst, z.B. "10 / 20", gibt es keine Fehlermeldung. Der Slash hat anscheinend ein Bedeutung für den Solr-Tokenizer. Ich vermute wir werden das über die Solr-Konfiguration lösen müssen. Wie genau, weiß ich noch nicht. Erst mal geht es darum den Anwendungsfehler zu vermeiden und dann darum, dass die Suchergebnisse immer noch den Erwartungen entsprechen.

[j3nsch]

Slash wird wohl als Anfang einer Regular Expression interpretiert. Im Testing Mode von OPUS 4 sieht man, dass die Exception im Solr generiert wird.

https://stackoverflow.com/questions/17798300/lucene-queryparser-with-in-query-criteria

Man kann Slash mit Backslash escapen, z.B. 10 \/ 20, aber in meinen Tests wird dann der String "10 / 20" in einem Titel nicht gefunden, es sei denn man nicht eines der beiden Leerzeichen in der Suchanfrage weg. Das Escapen verhindert auf jeden Fall den Anwendungsfehler. Man könnte auch die Slashes komplett entfernen, wenn vor ihnen ein Leerzeichen steht. Die Suchergebnisse scheint das nicht zu ändern.

@bfalkenstein, @stconradr, @vgerlach Vielleicht kann im Hosting experimentiert werden und dann könnt Ihr mir Eure Meinung sagen.

Wenn wir die Slashes manipulieren, brechen wir natürlich auch die Regular Expression Suche. Das hat aber vermutlich noch nie jemand in OPUS 4 verwendet. Ich habe es mal versucht. Manche Ausdrücke schienen zu funktionieren, aber nicht alles was ich erwarten würde. Ihr könnt ja auch damit mal experimentieren.

[j3nsch]

Ich habe mal zwei Titel mit den Worten "Big" und "Fig" erzeugt. Wenn ich nach big fig suche bekomme ich keinen Treffer, weil beide Worte vorhanden sein müssen. Der Query big OR fig liefert beide Titel und die Anfrage /big|fig/ liefert auch beide Titel. Die beiden Worte hatte ich gewählt, weil ich /[bf]ig/ testen wollte, aber das funktioniert nicht, obwohl es zumindest in der alten Solr-Dokumentation beschrieben ist (ab 4.0.0). In der aktuellen Dokumentation habe ich das noch nicht wieder gefunden.