Ich hoffe, jemand kann mir helfen oder mich in die richtige Richtung lenken.HTML-Antwort ändern (keine Kopfzeilen)
Ich wurde gebeten, herauszufinden, wie man Akamai (oder irgendein anderes CDN oder NGINX) den tatsächlichen Antwortkörper ändern lässt.
Warum?
Ich bin die CDN ändern alle "http: //" Anfragen auf "https: //", anstatt den App-Code zu ändern, um "//" für externe Ressourcenanforderungen zu verwenden.
Ist das möglich?
Wer weiß?
Dies scheint möglich über eine Reihe verschiedenen Ansätze zu sein, aber das ist nicht zu sagen, wie ratsam es könnte in der Tat sein.
Es scheint möglicherweise problematisch (Beispiel: Was, wenn Sie etwas umschreiben, das nicht neu geschrieben werden sollte?) Und Maschinen-ressourcenintensiv (eine Menge CPU-Zyklen wiederholt zu analysieren und Munge-Antwortkörper).
Hier ist, was ich gefunden habe:
Nginx die http_sub_module hat, dass dies in einer ziemlich einfache Art und Weise zu erreichen scheint, wollen einfach zu ersetzen, was Sie unter der Annahme ist, und Sie müssen nur pro Seite ein Muster entsprechen, wie <a href="http://example.com/... ersetzen mit <a href="https://example.com/..., einmal oder mehrmals. Diese Art von Content-Mungery scheint skizzenhaft, aber abhängig von der Situation, in der Sie sich befinden (die eine der eingeschränkten Kontrolle über die Anwendung sein kann) es könnte bekommen Sie dort.
Es sieht so aus, als gäbe es etwas namens http_substitutions_filter, möglicherweise inoffiziell oder zumindest nicht Teil der Kern-Nginx-Distribution, die leistungsfähigeres filterbasiertes Umschreiben von Antwortstellen durchführen kann.
Varnish seems to have eine ähnliche Fähigkeit (möglicherweise ein Plugin), aber HAProxy doesn't, da es nur in Kopfzeilen und Blätter Körper allein behandelt, außer wenn Gzip Offloading. Andere Reverse-Proxy-fähige Software wie Apache oder Squid bietet möglicherweise auch etwas Nützliches, das Sie vor Ihren Anwendungsserver stellen könnten.
Mein erster Eindruck, in jedem Fall ist, dass einfache Zeichenfolge ersetzen Sie nicht ganz dorthin bringen, und sogar Regex-basierte Ersetzen ist nicht wirklich ausreichend, ohne erhebliche Komplexität in den Regexes, weil Sie immer das Risiko laufen etwas neu schreiben, das du nicht solltest.
Was ich vorschlagen würde "wirklich muss geschehen", um diesen Zweck in der richtigsten Weise zu erreichen, wäre, das generierte HTML mit einer DOM-Parsing-Bibliothek zu interpretieren, den Baum zu durchqueren und die relevanten Elemente in zu verändern vor der Übergabe des überarbeiteten Dokuments an den Anforderer. Auf diese Weise wird das Dokument basierend auf einem kontextuellen Verständnis seiner Inhalte modifiziert.
Es klingt kompliziert, meiner Meinung nach, weil es ist - so würde ich wieder vorschlagen, dass Sie Ihren geplanten Ansatz überdenken, es sei denn, dies ist außerhalb Ihrer Kontrolle.
Endgültiger Gedanke: Curiosity hat das Beste von mir, also nahm ich diese Frage und rüstete den HTTP-Reverse-Proxy, den ich schrieb (für einen anderen Zweck), so dass er basierend auf dem Inhaltstyp tatsächlich analysieren und laufen konnte HTML-Struktur als eine richtige Entität, die an Ort und Stelle (wie oben beschrieben) geändert wird, bevor der Antworttext an den Anforderer zurückgegeben wird.
Dies stellt sich, wie ich erwartet habe, als ziemlich prozessorintensiv heraus. Mein Testinhalt war 29K Real-World HTML von einer Live-Site mit 56 <a href ...> und 6 <link rel ...> Elementen, und die Neuschreiboperation benötigte 128 ms auf einem 1 GHz Opteron 1218 und 43 ms 2,4 GHz Xeon E5620. Diese Benchmarks gelten ausschließlich für die zusätzlichen Operationen - mit Ausnahme der (kleineren) Zeit, die für die eigentliche "Proxy" -Funktionalität selbst benötigt wird. Dieser Zeitaufwand ist nicht unüberwindbar, könnte aber zu einer Menge CPU-Zeit führen. Dies ist viel länger als eine reguläre Ausdruck-basierte Inhaltsumschreibung würde dauern, aber es ist viel präziser und unwahrscheinlich, die Seiten zu brechen, die es berührt.
Nginx des HttpSubsModule groß für mich gearbeitet: http://wiki.nginx.org/HttpSubsModule
Wechsel von http auf https sollte so einfach wie diese:
location/{
subs_filter_types text/html text/css text/xml;
subs_filter http.example.com https.example.com gi;
}
Genau das gleiche, aber die korrekte Syntax.
location/{
sub_filter_types text/html text/css text/xml;
sub_filter 'http.example.com' 'https.example.com';
}