• Das Erstellen neuer Accounts wurde ausgesetzt. Bei berechtigtem Interesse bitte Kontaktaufnahme über die üblichen Wege. Beste Grüße der Admin

[js]Textdatei zyklisch mit Ajax einlesen

gerade beim IE muss man darauf achten das man nicht das Browsereigene XHR-objekt nimmt, sondern das systemweite XHR-objekt. mindestens der IE7 hat probleme mit der SOP bei lokalen requests mit dem eigenem XHR-objekt.
Was ist denn bei einer mittels file:// aufgerufenen Datei ohne lokalen Webserver ein "lokaler Ajax Request" nach deiner Definition?

Ich schrieb von Ajax Requests gegen beliebige Webserver aus einer Datei die man lokal mittels file:// aufruft, weil mir das als das nächstliegende Szenario erschien und vor allem, weil es in diesem Thread darum geht.
Da kommt im IE ein Warnhinweis, ob man Inhalte zulassen will, den man bestätigt und danach fluppt das.
Das geht hingegen in keinem anderen mir bekannten Browser außer noch Safari.
 
Was ist denn bei einer mittels file:// aufgerufenen Datei ohne lokalen Webserver ein "lokaler Ajax Request" nach deiner Definition?
die frage verstehe ich nicht so ganz!
ich habe auf meiner festplatte eine HTML-Datei.
diese öffne ich ganz normal mit einem doppelklick.
neben der HTML-Datei liegt noch eine textdatei.
auf diese mache ich einen request.
das ist lokal
das ganze (HTML-Datei und textdatei) kann man dann auch auf einen server hochladen und die HTML-Datei dann über diesen öffnen und es funktioniert genauso nur dann über den server.


nicht in diesem thread


Ajax Requests gegen beliebige Webserver aus einer Datei die man lokal mittels file:// aufruft,
das darf wegen der sop nicht gehen

weil mir das als das nächstliegende Szenario erschien
mir nicht, Szenarien für mich wären
* lokale html-seiten auf z.B. einem USB-Stick für die ich keinen lokalen Server (server2go) benötige für z.B. Dokumentationen
* schnelle lokale tests

und vor allem, weil es in diesem Thread darum geht.
in diesem thread?

Da kommt im IE ein Warnhinweis, ob man Inhalte zulassen will, den man bestätigt und danach fluppt das.
echt? wundert mich ein wenig, habe ich allerdings noch nie probiert
 
ich habe auf meiner festplatte eine HTML-Datei.
diese öffne ich ganz normal mit einem doppelklick.
neben der HTML-Datei liegt noch eine textdatei.
auf diese mache ich einen request.
das ist lokal
OK, einverstanden.

das darf wegen der sop nicht gehen
Ja, eben. Tut es aber doch und zwar im IE und im Safari. Gern auch noch ein fünftes und sechstes mal :)

in diesem thread?
Ich war davon ausgegangen, dass die gewünschte Datei über einen Webserver ausgeliefert werden soll, es sich also um einen Request und keinen Dateizugriff handelt.

echt? wundert mich ein wenig, habe ich allerdings noch nie probiert
Ja, echt. Auch gern noch ein siebtes mal :)
Probiers gern mal aus.

Und danch möchte ich das bitte gerne in diesem Forum nie wieder in Zweifel gestellt sehen, sonst :boxing:
 
Ja, eben. Tut es aber doch und zwar im IE und im Safari. Gern auch noch ein fünftes und sechstes mal :)
Wenn du von einem x-belibigen Host auf ein file:// zugreifst?
Dann bekomme ich im IE einen Fehler:
Code:
Details zum Fehler auf der Webseite

Benutzer-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)
Zeitstempel: Wed, 13 Feb 2013 08:58:26 UTC


Meldung: Zugriff verweigert

Zeile: 122
Zeichen: 4
Code: 0
URI: http://192.168.178.23/javascript/ajax.js
 
Über das File:// Protokoll? Das geht im firefox nicht. https://bugzilla.mozilla.org/show_bug.cgi?id=331610
Im Chrome kannst du es einstellen: https://code.google.com/p/chromium/issues/detail?id=40787
Achtung, zu diesem Zeitpunkt meinte hesst bereits Dateizugriffe per Ajax, nicht "normale" Server Requests, wie sich jetzt herausstellte.
Und bei einer per file:// aufgerufenen - also lokalen - Datei einen Ajax Request gegen eine lokale Datei zu machen ist ja dann wieder nicht mehr SOP schädlich.
 
Im Browser sind "Normale Dateizugriffe" das File:// Protokoll, oder was meinst du jetzt?

Edit: Alles sehr verwirrend hier. Ja, Zugriff per File:// ist nicht SOP schädlich, zumindest nicht per Definition. Mozilla hat das Protokoll wohl aus grundsätzlichne Erwägungen für AJAX gesperrt. Halte ich auch für nicht verkehrt.
 
Zuletzt bearbeitet:
Im Browser sind "Normale Dateizugriffe" das File:// Protokoll, oder was meinst du jetzt?
Verwirrung pur.
Also.
Es gibt zwei Formen, eine HTML Dokument in den Browser zu laden. Einmal durch Dateizugriff und per Request gegen irgend einen Server.

Und dann gibt es noch zwei Formen, was dieses geladene Dokument wiederum für einen Zugriff macht. Nämlich auch wieder entweder auf eine lokale Datei oder als Serverrequest.

Du und ich reden davon, dass das Dokument einen Serverrequest gegen einen Webserver macht.
Dabei ist natürlich entscheidend, ob das Dokument lokal als file:// geladen wurde oder über einen Server. Denn die SOP würde die Ausführung des enthaltenen JS verbieten, wenn man ein Dokument per file:// lädt welches dann einen Serverrequest ausführen will. Ausnahme: IE und Safari.

hesst hingegen ging davon aus, dass das Dokument sowohl per file:// geladen wurde als auch per file:// einen lokalen Dateizugriff durchführt. Dann wiederum ist die SOP nicht im Wege und auch der Firefox spielt dann mit.

So zumindest habe ich das verstanden, obwohl meine Dokumente nie auf irgendwelche lokalen Dateien zugreifen. Das kenne ich nur aus dem mobilen Umfeld, wo ich nicht aktiv bin.
Was ich hingegen während einer Entwicklung öfter mache ist, ein Dokument per file:// lokal zu öffnen und das darin enthaltene Ajax einen Serverrequest gegen einen Webserver durchführen zu lassen, um es zu testen.
Und da bin ich sehr froh, dass das der IE als einziger Browser auf Windows-Oberflächen zuläßt.
 
Zuletzt bearbeitet:
Ja, eben. Tut es aber doch und zwar im IE und im Safari. Gern auch noch ein fünftes und sechstes mal :)
das brachtest du gerade das 1. mal an

Ich war davon ausgegangen, dass die gewünschte Datei über einen Webserver ausgeliefert werden soll, es sich also um einen Request und keinen Dateizugriff handelt.
vielleicht, getestet hat er aber erst mal lokal gegen ein lokales file(sieht man auch am code). das man das ganze dann auch auf einen server laden kann(alles), ist in diesem zusammenhang erst mal egal

Über das File:// Protokoll? Das geht im firefox nicht. https://bugzilla.mozilla.org/show_bug.cgi?id=331610
der HTTP-status ist 0, ja! auch im ie, das heisst aber nicht, dass der request nicht gemacht wird.

Du und ich reden davon, dass das Dokument einen Serverrequest gegen einen Webserver macht.
nein, nur du redes davon

hesst hingegen ging davon aus, dass das Dokument sowohl per file:// geladen wurde als auch per file:// einen lokalen Dateizugriff durchführt. Dann wiederum ist die SOP nicht im Wege und auch der Firefox spielt dann mit.
genau darum geht es hier ja auch
 
der HTTP-status ist 0, ja! auch im ie, das heisst aber nicht, dass der request nicht gemacht wird.
Stimmt, das war mir nicht bewußt. Da ich sowas bisher nie gebraucht hatte und immer nur auf den Status getestet habe, aber ich habe es gerade ausprobiert, man kann status == 0 als Erfolgreiche Übertragung betrachten.
 
POST hat den Vorteil, dass es nicht cached. Ich nutze GET deshalb garnicht mehr. Egal worum es geht. Die Unterscheidung nach Abfrage und Senden ist mit Ajax veraltet und nicht mehr relevant, da man heutzutage sowieso bei jedem Request etwas sendet und etwas abholt. Wo will man da noch einen Unterschied machen.

1. ich kann durch setzten von Headern auch verhindern, dass GET Requests gecached werden.
2. Das sich das mit AJAX erledigt hat halte ich für unsinn. Eigentlich alle Firmen mit denen ich zu tun habe, erwarten bei einer API beispielsweise einen REST Service und dort ist dies Unterscheidung sinnvoll und notwendig zum sauberen Aufbau
3. "bei jedem Request etwas sendet und etwas abholt". Das war doch früher nicht anders, du hattest eine URL (mit oder ohne parameter) und der Aufruf gab etwas zurück (und wenn es eine leere Seite war). Dazu ein kleines Zitat:
HTTP schreibt vor, dass GET „sicher“ (englisch safe) sein muss, was bedeutet, dass diese Methode nur Informationen beschafft und keine sonstigen Effekte verursacht. Die Methoden GET, HEAD, PUT und DELETE müssen laut HTTP-Spezifikation idempotent sein, was in diesem Zusammenhang bedeutet, dass das mehrfache Absenden der gleichen Anforderung sich nicht anders auswirkt als ein einzelner Aufruf
und netsprechend noch ein Link zur Umsetzung von REST (jaja wikipedia ist nicht zitierfähig plapla. aber hier tut es mal seinen Dienst): Representational State Transfer

Lg Kasalop
 
1. ich kann durch setzten von Headern auch verhindern, dass GET Requests gecached werden.
Ist das deiner Meinung nach in allen Browsern zuverlässig?

Eigentlich alle Firmen mit denen ich zu tun habe, erwarten bei einer API beispielsweise einen REST Service und dort ist dies Unterscheidung sinnvoll und notwendig zum sauberen Aufbau
Ja, für API Requests, das ist was anderes. Ich sprach von 0815 Requests gegen stinknormale Webserver, die garnicht abfragen, wie der Request kommt.

3. "bei jedem Request etwas sendet und etwas abholt". Das war doch früher nicht anders, du hattest eine URL (mit oder ohne parameter) und der Aufruf gab etwas zurück (und wenn es eine leere Seite war).
Ich bin nicht ganz sicher aber ich meine mich zu erinnern, dass man in den Anfängen des www bei GET Anfragen noch keine Parameter mitgeben konnte. Das heißt, in der URL Zeile des Browsers ging höchstens noch ein Dokumentenanker (der natürlich im Browser verblieb) mit # aber mehr nicht.
Oder erinnere ich mich da falsch?

genau darum geht es hier ja auch
Dann entschuldige ich mich. Das ist mir entgangen. Will er denn eine mobile Anwendung bauen oder wofür braucht man das sonst noch? Ich wüßte dafür garkeine Anwendung.
 
Ist das deiner Meinung nach in allen Browsern zuverlässig?
Ja schon. mir wäre jetzt kein Browser bekannt, bei dem das nicht so wäre.

Ja, für API Requests, das ist was anderes. Ich sprach von 0815 Requests gegen stinknormale Webserver, die garnicht abfragen, wie der Request kommt.
hm. Nur zur sicherheit: Meinst du jetzt alle AJAX Requests, oder ALLE Requests (also auch wenn man einen Link anklickt der eine normale verlinkung zur folge hat)

Ich bin nicht ganz sicher aber ich meine mich zu erinnern, dass man in den Anfängen des www bei GET Anfragen noch keine Parameter mitgeben konnte. Das heißt, in der URL Zeile des Browsers ging höchstens noch ein Dokumentenanker (der natürlich im Browser verblieb) mit # aber mehr nicht.
Oder erinnere ich mich da falsch?
Also seit definition der URI (RFC 1630) gibt es auch parameter. Ich nehme an es kommt drauf an wie du Anfang des www definierst. Aber ich wüsste jetzt nicht, dass es das noch nicht gab. Und selbst wenn ist ja auch die angabe von unterschiedlichen Dateinamen eine Adressierung (Parametrisierte) Anfrage, nur eben im Pfad enthalten (wie wenn ich heute /index/5/2 aufrufe. Ob das nun ein echtes Verzeichnis oder ein durch mod_rewrite simuliertes ist, ist ja völlig egal)

Lg Kasalop
 
Ja schon. mir wäre jetzt kein Browser bekannt, bei dem das nicht so wäre.
Wie genau sähe dieser Header bei dir aus?

hm. Nur zur sicherheit: Meinst du jetzt alle AJAX Requests, oder ALLE Requests (also auch wenn man einen Link anklickt der eine normale verlinkung zur folge hat)
Hab den Faden verloren. Lass es uns nicht vertiefen. GET und POST wählt man nach den Vorgaben des Servers und ansonsten ist es eine Glaubenssache. Kompromiss? :)
 
@mikdoe:
PHP:
header("Cache-Control: no-cache");
header("Pragma: no-cache");
header("Cache-Control: max-age=0");
damit funktioniert's im IE7-9 (der ja das Sorgenkind ist).
 
Zurück
Oben