Problem beim MIME-Typ im Internet Explorer mit Proxy

Question

In Internet Explorer wird die angeforderte URL aufgrund fehlender MIME-Typen blockiert. In diesem Szenario wird die Anforderung vom Client über einen Proxyserver an den Zielserver gesendet. Angenommen, wir haben A (Client), B (Proxy Server), C (Zielserver). Die Anfrage geht von A (Client) zu B (Proxy-Server) und von B (Proxy-Server) zu C (Zielserver). In ähnlicher Weise kommt die Antwort auch von C (Zielserver) zu B (Proxyserver) und von B (Proxyserver) zu A (Client), von wo die Anfrage initiiert wurde. Nun ist das Problem, dass die Response Content-Type "application/liquid" ist, aber der Client feuert die Anfrage mit dem "script src = proxyserver/test" ab, so dass der ausgenommene Content-Type für response "text/javascript" wird. Es ist nicht erlaubt, den Inhaltstyp der Antwort von "Anwendung/Flüssigkeit" des Zielservers zu ändern. Das ganze Szenario funktioniert perfekt in allen anderen Browsern und die Antwort ist leicht zugänglich. Jedoch in IE, da wir den Fehler als "Anfrage wegen Mime-Typ-Konflikt" gesperrt bekommen. Kann also jemand die Lösung bereitstellen, wie könnten wir es zum Funktionieren bringen? Unten ist der Screenshot des Fehlers.

Answer 1

Sie müssen ein Skript erstellen, ein externes Skript, das den Aufruf des gewünschten Codes mit einem Ajax-Aufruf oder xmlhttprequest, wo Sie die Annahme Header so den gewünschten Mime-Typ festlegen müssen. Vom Client wird es das externe Skript mit dem Skript-Tag aufrufen, das über den Proxy-Server ausgeführt wird und den Aufruf an die tatsächlichen Daten weitergibt und seine Antwort empfängt und an den Client zurücksendet. Aber wie es das Skript aufrufen wird, würde Header standardmäßig als Text/Javascript zurückgeben und der Fehler wird gelöst.

Answer 2

TL; DR - Sie werden die MIME-Typen zu ändern.

Dieses Problem tritt auf, wenn sich der erwartete Typ der Anforderungen vom Antwort-Inhaltstyp unterscheidet (wie durch die Header angegeben). Die richtige Lösung wäre, die Antwort- und Anforderungsheader miteinander kompatibel zu machen. Das heißt, der Anruf, den Sie "über ein Skript-Tag" tätigen, sollte so geändert werden, dass derselbe Header accept wie der Header der Antwort lautet content-type.

Werfen Sie auch einen Blick in die Dokumentation:

NOSNIFF Blocks eine Anfrage, ob der angeforderte Typ „Stil“ und die MIME Typ ist nicht „text/css“ oder „Skript“ und die Der MIME-Typ ist kein JavaScript-MIME-Typ .

Siehe here.

Ich sehe, dass diese URL: https://nirma.myshopify.com/apps/GeoShippingBar/geoShippingBarProxy hat diesen Content-type: Content-Type:text/html; charset=utf-8 die nicht Javascript-Mime-Typ ist.

Answer 3

Grundsätzlich können Sie dies nicht tun. App Proxys dienen zum Erstellen von Seiten, nicht von Skriptdateien.

Eine mögliche Strategie, die Sie erhalten, wo Sie gehen wollen, ist wie folgt:

Die dynamische aus flüssigen Teile in einen Schnipsel werden kann.

<script type="text/javascrpt"> 
    geoShippingConfig = { 
     somevalue: '{{ shop.X }}', 
     etc 
    }; 
</script> 

Und Sie injizieren das in das Hauptlayout, wenn Ihre App installiert ist. Verschiedene Apps machen so etwas. Sie müssen den Kunden warnen, dass Sie dazu gehen werden, aber es ist ziemlich gutartig. Sie benötigen auch eine Schaltfläche zum Aktualisieren oder eine Möglichkeit, das Snippet und das Include erneut einzufügen, wenn sich das Design ändert.

Dann installiert Ihre App ein Script-Tag mit Ihrem Code, anstatt einen App-Proxy aufzurufen. Skript-Tags enthalten den Shop in der URL, sodass Sie für die zurückgegebene Skriptdatei eine appspezifische Konfiguration vornehmen können. Ihr Script-Tag-Skript verwendet beim Laden load.conf.

Answer 4

Versuchen Sie folgendes:

Response.AddHeader ("annehmen", "text/javascript");

in der Antwort des Skript-Tags von wo es aufgerufen wird.