Internet Textur Download schlägt fehl

Ich habs gerade auch mal mit deiner Datei versucht und dazu schnell eine neue "nile.itx" geschrieben

http://media.omsi-tools.de/itx-test.tga
Sceneryobjects\niletest\texture\nile.tga

https://media.omsi-tools.de/itx-test.tga
Sceneryobjects\niletest\texture\nile_s.tga

(mal beide Varianten versucht ... nicht dass OMSI nur kein https mag)

Ergebnis war das gleiche erfolglose wie bei dir. (Information: Problem while getting file...)

Dann hab ich deine direkt mit dem Browser heruntergeladene tga-Datei auf meinen Server gepackt, den Link in der itx auf meinen Server geändert ... und die Datei wurde sofort beim OMSI_Start (der dann auch wieder etwas schneller war) problemlos runtergeladen und im gewünschten Ort im OMSI-Verzeichnis gespeichert.

Ich vermute, dass dein Server aus irgendwelchen Gründen die Anfrage von OMSI blockt.

Fehlersuche also wohl nicht bei OMSI, sondern bei deinen Servereinstellungen.

Was hast du denn für "Sicherheitsvorkehrungen" bei deinem Server? Bei mir habe ich ein SSL-Zertifikat und HSTS aktiv (hier eigentlich egal, da sowieso HTTPS). Nur habe ich halt zwischendurch das Problem, dass Filezilla mit ein ungültiges Zertifikat meldet. Kann mir aber nicht vorstellen, dass OMSI damit ein Problem haben könnte.

Spontaner Gedanke gerade noch - könnte es eventuell sein, dass OMSI Probleme mit HTTPS hat? Mit meinen Links könnte es dann nicht funktionieren, da sie immer auf HTTPS umgeleitet werden. Und ich bin mir gerade auch nicht mehr sicher, wie sehr ich das mit HTTP(S) damals beim Schreiben des Artikels geprüft habe.

Hatte ich ja geschrieben ... bei deinem Server hats so nicht funktioniert.

Bei meinem eigenen dagegen schon. (Der Link stand nun nicht im Beitrag - aber wenn du es testen willst schreib das in itx. Noch liegt die Datei dort. Und wahrscheinlich müssen auch die Ordner "Sceneryobjects\niletest\texture\" in OMSI vorhanden sein. Kannst aber natürlich genauso nur den Link ändern und den Ruede-Ordner wie bei dir stehen lassen.)

http://grakl.de/OMSI/itx-test.tga
Sceneryobjects\niletest\texture\nile.tga

Zumindest sollte so eben klar sein, dass das Problem weder OMSI, noch die Datei ist, sondern dein Server. Möglicherweise irgendwelche Sicherheitseinstellungen, die die OMSI-Anfrage blocken.

Schau mal einer an, mein HTTP-Test funktioniert:

Hab da mal kurz eine neue Subdomain, die SSL aktiv, aber diesen Rest hier nicht aktiv hat:

http://http.omsi-tools.de/itx-test.tga            ---Geht
Sceneryobjects\niletest\texture\1.tga

https://media.omsi-tools.de/itx-test.tga          ---Geht nicht
Sceneryobjects\niletest\texture\2.tga

Nile, wo hast du denn deinen Server? Ich bin bei netcup, da habe ich unter jeder Domain die Möglichkeit, SSL und diese weiteren Einstellungen zu definieren.

Hier müsste es ja unter den Admins doch ein paar geben, die von Servern im Gegensatz zu mir Ahnung haben. Vielleicht hat da einer einen Tipp.

Allerdings ist das mit Sicherheitsrestriktionen eh nur eine reine Vermutung von mir - aber ich wenns auf einem Server geht und auf dem anderen nicht, muss es ja irgendeinen Grund haben.

Zitat von Bamp

Code: itx

http://http.omsi-tools.de/itx-test.tga            ---Geht
Sceneryobjects\niletest\texture\1.tga

https://media.omsi-tools.de/itx-test.tga          ---Geht nicht
Sceneryobjects\niletest\texture\2.tga

Hier ist der Unterscheid aber mehr als nur http/https (ich hatte es ja auch mit http bei Nile versucht)

Das was funktioniert hat ja gar nicht mehr die Subdomain "media.", sondern stattdessen http als Subdomain ???

Die Subdomain "http" ist nur der Name der Domain, der hat mit der eigentlichen Funktionsweise nicht wirklich viel zu tun. Unterschiede:

media.omsi-tools.de	http.omsi-tools.de
Zugriff via https	Zugriff via http
SSL vorhanden	SSL vorhanden

Ich habe die http-Subdomain gerade nochmal mit https (als Zugriffstyp) getestet, da bekomme ich auch einen Fehler. Also irgendwie scheint das (bei meinem Server zumindest) an dieser http/https-Geschichte zu liegen, weil es funktioniert ja nur mit http-Zugriff.

Bamp

Öhem ... peinlich.

Hab die ganze Zeit deinen Server als Test genutzt, in der Annahme, dass es Niles ist (hatte irgendwie einfach den letzten Link auf der vorherigen Seite kopiert.)

Aber sind es wirklich die https-Einstellungen?

Bei meinem Server, wo es mit http funktionierte, gibts zwar https - aber keine Zwangsumleitung, wenn http aufgerufen wird.

Bei dir mit media. wird https erzwungen und es klappt nicht.

Bei Nile schein dagegen kein https erzwungen zu werden - trotzdem klappt es bei ihm nicht.

Für heute reichts. Morgen kann ichs gern selbst nochmal direkt mit Niles Server versuchen

Zitat von hajo

Hab die ganze Zeit deinen Server als Test genutzt, in der Annahme, dass es Niles ist

Hab ich mir irgendwie schon gedacht, wollte es dann aber doch nicht schreiben...

Puh, ja da merkt man jedenfalls wieder, wie blöde das mit OMSI manchmal ist. Am ehesten würde ich da tatsächlich drauf tippen, dass bei Nile die OCSP-Anheftung (irgendwas mit Datenschutz, dass das Zertifikat von dem Server selbst oder so aufgerufen wird - da: Wenn ich auf http.omsi-tools.de OCSP aktiviere, geht es nicht (wenn ichs auf media aus mache, geht aber auch nicht. Vielleicht ist einfach die Mischung aus http und keinem OCSP notwendig?). Kann mir aber wie gesagt nicht vorstellen, dass OMSi auf sowas Rücksicht nehmen würde halt, ich habe da verpennt, dass ich noch https bei der http-Domain drinne hatte... es geht auch mit OCSP.

Ich bin aber auch langsam mit meinem Latein am Ende - vielleicht kann Wörki ja noch was sagen?