Hallo klawischnigg, nur zur Sicherheit: wird der iframe mit sandbox-Attribut erstellt? > "Reine" JS-Dateien werden übrigens problemlos geladen. > Es hat klarerweise etwas mit "same-origin"-etc. zu tun Das würde zu Felix Aussage passen. MDN schreibt: > The Access-Control-Allow-Headers response header is used in response to a preflight request which includes the Access-Control-Request-Headers to indicate which HTTP headers can be used during the actual request. Und ein preflight request ist ein OPTIONS Request, also kein GET oder POST, und es ist natürlich gut möglich, dass da wegen des iframe ein Preflight gemacht wird und dein Server oder dein PHP Script mit dem OPTIONS Request nicht klar kommt. Oder PHP als Handler für dieses Verb nicht eingerichtet ist. Das sollte sich aber aus dem Text der HTTP 500 Meldung oder dem Server-Log ergeben. Wenn es ein OPTIONS Request ist, musst Du den wohl entsprechend behandeln. Ich weiß nicht, ob es sinnvoll ist, die Header prinzipiell zu setzen. _Rolf_ -- sumpsi - posui - obstruxi

Hallo klawischnigg, nur zur Sicherheit: wird der iframe mit sandbox-Attribut erstellt? > "Reine" JS-Dateien werden übrigens problemlos geladen. > Es hat klarerweise etwas mit "same-origin"-etc. zu tun Das würde zu Felix Aussage passen. MDN schreibt: > The Access-Control-Allow-Headers response header is used in response to a preflight request which includes the Access-Control-Request-Headers to indicate which HTTP headers can be used during the actual request. Und ein preflight request ist ein OPTIONS Request, also kein GET oder POST, und es ist natürlich gut möglich, dass da wegen des iframe ein Preflight gemacht wird und dein Server oder dein PHP Script mit dem OPTIONS Request nicht klar kommt. Das sollte sich aber aus dem Server-Log ergeben. Wenn es ein OPTIONS Request ist, musst Du den wohl entsprechend behandeln. Ich weiß nicht, ob es sinnvoll ist, die Header prinzipiell zu setzen. _Rolf_ -- sumpsi - posui - obstruxi