it-swarm.com.de

Wie ersetze ich Zeichen in einer Nginx-Variablenzeichenfolge?

Kann ich nicht alphanumerische Zeichen, die mit $request_uri zurückgegeben wurden, durch ein Leerzeichen (oder einen +) ersetzen?

Ich versuche, alle 404 auf einer meiner Websites an die Suchmaschine weiterzuleiten, in der die Abfrage den angeforderten urienthält. Also habe ich einen Block in meiner nginx.conf mit:

error_page 404 = @notfound;
location @notfound {
    return 301 $scheme://$Host/?s=$request_uri;
}

Während dies in der Tat funktioniert, sind die URLs, die zurückgegeben werden, die tatsächlichen uriname__s, die mit -_/-Zeichen versehen sind, wodurch die Suche immer 0 Ergebnisse zurückgibt

Zum Beispiel ... gib diese URL ein: https://example.com/my-articles, die Weiterleitung endet wie folgt: https://example.com/?s=/my-articles

Was ich möchte, ist, (letztendlich) so zu enden: https://example.com/?s=my+articles (obwohl das + am Anfang auch gut funktioniert ... https://example.com/?s=+my+articles

Ich muss dies ohne LUA- oder Perl-Module tun. Wie kann ich das erreichen?

2
Kevin

Möglicherweise müssen Sie dies anpassen, je nachdem, wie weit in Ihrer Verzeichnisstruktur der Austausch erfolgen soll. Dies ist jedoch das Grundkonzept.

Benannter Speicherort für die erste Erfassung von 404s:

location @notfound {
  rewrite (.*) /search$1 last;
}

Benannte Speicherorte sind ein wenig einschränkend, so dass dies alles am Anfang des URIs, der 404 zurückgegeben hat, /search/ hinzufügt. Das Flag last weist Nginx an, den aktuellen Standort zu verlassen und den besten Ort für die Verarbeitung der Anforderung basierend auf dem umgeschriebenen URI auszuwählen , also brauchen wir einen Block, um das zu fangen:

location ^~ /search/ {
  internal;
  rewrite ^/search/(.*)([^a-z0-9\+])(.*)$ /search/$1+$3 last;
  rewrite ^/search/(.*)$ /?s=$1 permanent;
}

Die internal-Direktive macht diesen Speicherort nur für den Nginx-Prozess selbst zugänglich. Alle Clientanforderungen an diesen Block geben 404 zurück.

Beim ersten Umschreiben wird der letzte Nichttext, die Ziffer oder das +-Zeichen in einen + geändert, und dann wird Nginx aufgefordert, den umgeschriebenen URI neu zu bewerten.

Der Standortblock wird mit dem Modifizierer ^~ definiert. Dies bedeutet, dass Anforderungen, die mit diesem Standort übereinstimmen, nicht anhand von durch Regex definierten Standortblöcken ausgewertet werden. Daher sollte dieser Block die neu geschriebenen Anforderungen einfangen.

Wenn alle Nicht-Word-Zeichen nicht mehr vorhanden sind, stimmt die erste Umschreibung nicht mehr überein, sodass die Anforderung an die nächste Umschreibung übergeben wird, wodurch der /search vor der URI entfernt und die Abfragezeichenfolge hinzugefügt wird.

Meine Protokolle sehen so aus:

>> curl -L -v http://127.0.0.1/users-forum-name.1
<<  "GET /?s=users+forum+name+1 HTTP/1.1"

>> curl -L -v http://127.0.0.1/users-forum-name/long-story/some_underscore
<< "GET /?s=users+forum+name+long+story+some+underscore"

Du hast die Idee..

1
miknik
  1. Es ist im Allgemeinen eine schlechte Idee, automatisch Weiterleitungen von 404 Not Found-Seiten an andere Stellen auszugeben. Möglicherweise hat der Benutzer ein einzelnes Zeichen in der URL falsch eingegeben (z. B. auf einem Mobiltelefon, während die URL aus einem Flieger kopiert wird und ein "dicker Finger" hat). Dies ist sehr einfach zu korrigieren, sobald ein 404-Code und der offensichtliche Tippfehler in der Adressleiste angezeigt werden. Es kann jedoch erforderlich sein, von vorne anzufangen, wenn Ihre Suchmaschine nicht liefert.

  2. Wenn Sie es dennoch tun möchten, ist es möglicherweise effizienter, dies innerhalb der Suchmaschine selbst zu tun. Wenn Ihre Suchmaschine nicht in der Lage ist, nach URL zu suchen und Tippfehler zu korrigieren, klingt dies nicht nach einem sehr nützliche Suchmaschine, jetzt?

  3. Wenn Sie es noch im Nginx allein vor der Suchmaschine tun möchten, können Sie die Tatsache nutzen, dass Sie mit den Anweisungen http://nginx.org/r/rewrite im Wesentlichen jede Art von DFA implementieren können - Deterministic Finite Automaton - Abhängig von der Anzahl der erforderlichen Ersetzungen kann dies jedoch zu vielen Zyklen und etwas unflexiblen Regelsätzen führen.

    Sehen Sie sich die folgenden Ressourcen zum rekursiven Ersetzen bestimmter Zeichen in der URL für andere Zeichen an:

0
cnst

Sie können das Lua-Modul verwenden und diese Variable mithilfe von Lua-String-Funktionen in das gewünschte transformieren. Ich benutze OpenResty, was im Grunde Nginx mit aktivierter Lua ist. Aber das Nginx Lua Modul wird gut funktionieren. Hier ist eine Direktive, mit der Sie Lua in der Nginx-Konfiguration verwenden können. Es könnte sich innerhalb des Speicherorts mit content_by_lua_block/access_by_lua_block oder in einer separaten Datei mit content_by_lua_file/access_by_lua_file befinden. Hier ist die Dokumentation zu diesem https://github.com/openresty/lua-nginx-module#content_by_lua . Hier ist ein Beispiel aus meiner App. 

location ~/.*\.jpg$ {

  set $test '';
  access_by_lua_block {

    ngx.var.test = string.sub(ngx.var.uri, 2)

  }
  root /var/www/luaProject/img/;
  try_files    $uri /index.html;


  }
0
Donm