FireFox-Problem mit Datei-verlinkung

[PieDie]

Ich denke mal, hier isses besser aufgehoben, weils eher um Syntax als ums Programm geht...

Folgendes:

Wir befinden uns auf der Seite einer Subdomain.

blub.firma.de

Die Seite ist eine intranet-Seite, die so aufgerufen wird

blub.firma.de/navigation.php

Ich verlinke auf dieser Seite folgendermaßen auf eine Datei:

<a href="file://BLUBNT03/Ornder/Datei.ext"

Problem:

Internet Explorer versucht, die Datei zu öffnen, alles gut alles super.

In der Statusleiste gibt er mir auch genau diese Adresse als Ziel an.

FireFox sagt in der Statusleiste das gleiche, macht aber nach einem Klick nichts weiter.

Wenn ich in die Adressleiste \\BLUBNT03\Ordner\Datei.ext

eingebe, klappts bei beiden Browsern.

wenn ich das aber in den Link schreibe, macht FireFox dicke Backen. (IE macht gutmütig ein file://blabla draus und das klappt)

Firefox macht daraus blub.dek.de/\\BLUBNT03\Ordner\Datei.ext

Das kann natürlich nicht klappen.

Kann man den Link so definieren, dass er die schreibweise

\\BLUBNT03\Ordner\Datei.ext

erzwingt=?

Warum packt Firefox ein blub.firma.de davor, nur weil er den Link auf einer Seite hat, die in dieser Domain liegt?

[geloescht_JesterDay]

Warum packt Firefox ein blub.firma.de davor, nur weil er den Link auf einer Seite hat, die in dieser Domain liegt?

Weil ein relativer Link sich eben immer auf die URL des verlinkenden Dokuments bezieht.

Ein Link pfad/dokument.ext im Dokument subdomain.domain.tld/dokument.ext kann sich ja nur auf das Dokument subdomain.domain.tld/pfad/dokument.ext beziehen und um dieses Dokument vom Server anzufordern muss der Pfad ergänzt werden.

Du kannst im Dokument die BaseUrl (SELFHTML: HTML/XHTML / HTML-Kopfdaten / Adressbasis und Zielfensterbasis) angeben, die als Basis für alle relativen Links verwendet werden soll.

Zu deinem Problem: file:///BLUBNT03/Ornder/Datei.ext (also 3 /)

Die 2 / sind der Trenner zum Protokoll, also file in dem Fall. Danach kommt der Pfad zum Dokument und ohne führendes / wird der als relativ zum aktuellen Ort des Dokuments angesehen, was ja vollkommen korrekt ist. Der IE macht das zwar auf den ersten Blick korrekt, aber ist es (wie so oft) halt nicht

[PieDie]

Macht Sinn, in die Richtung hab ich auch schon vermutet.

Aber mit 3 / kann Firefox genausowenig anfangen. Das ist ja das Problem.

Der IE kann damit übrigens auch nichts anfangen.

Genausowenig mit ../../ wie es auch bei SelfHTML zu finden ist.

Ob ich nun BLUBNT03.firma.tld nehme oder nur BLUBNT03... Macht keinen Unterschied. NIx passiert

file://BLUBNT03.firma.tld/Ordner/Datei.ext -> Geht im IE (fälschlicherweise...)

file:///BLUBNT03.firma.tld/Ordner/Datei.ext -> Geht in keinem Browser

Ich kann ja bei zweiter Variante nichtmal Ziel speichern unter machen. FireFox juckt das überhaupt nich. Er sieht da zwar nen link, gedenkt aber nicht, bei einem Klick entpsrechend zu handeln.

Wenn ich file in http umändere, bekomme ich nur Meldungen der Marke "Seite nicht gefunden"...

[geloescht_JesterDay]

Aber mit 3 / kann Firefox genausowenig anfangen. Das ist ja das Problem.

Der IE kann damit übrigens auch nichts anfangen.

Also ich hab extra in unserem (internen) Wiki nachgesehen, da haben wir auch File-Links:

file:///X:/Pfad/Directory/Datei.ext

Wird da im FF ohne Prob angezeigt und im IE auch (Textdatei hab ich grad probiert).

U.U. kann der FF ja mit dem Dateityp nix anfangen?

[Crash2001]

Da ist LW X aber dann ein Netzlaufwerk, das bei jedem gemountet ist, oder?

[geloescht_JesterDay]

Da ist LW X aber dann ein Netzlaufwerk, das bei jedem gemountet ist, oder?

Da ist Laufwerk X: ein Platzhalter, den du mit einem Laufwerk deiner Wahl (oder Laufwerksvergabe) füllen kannst

[PieDie]

Die Dateien sind nicht auf Netzlaufwerken. das ist also belanglos

In unserem Wiki sind auch Files auf den Upload-Ordner verlinkt:

http://wiki.firma.de/uploads/file.ext

Da fragt Firefox dann auch brav, was zu tun sei. Der Internet Explorer macht dann auch, was er soll.

Ich vermute, es liegt dann irgendwie am Server, auf dem die Files liegen...

[geloescht_JesterDay]

Ich vermute, es liegt dann irgendwie am Server, auf dem die Files liegen...

Was wird denn vom Server an FF zurückgeschickt?

Stichwort: mozdev.org - livehttpheaders: index

[PieDie]

Auf

http://BLUBNT03.firma.tld/Ordner/File.ext

Liefert FF wie IE folgendes:

Kommunikationsfehler Zu keinem der konfigurierten Web Component Server konnte eine Kommunikationsverbindung hergestellt werden, da sie momentan nicht zur Verfügung stehen oder ausgefallen sind. Wenn dieses Problem weiterhin bestseht, wenden Sie sich an Ihren Systemadministrator.

Liegt in irgendeiner Form also am Server. Sieht mir nicht aus, wie eine Default Fehlermeldung der beiden. Die verlinkten Files sind über eine Freigabe verfügbar. Daher klappt folgendes auch:

\\BLUBNT03(.firma.de)\Ordner\File.ext

Das in die Adressleiste gekloppt machen beide Browser was sie sollen ohne Murren. Gibts einen Trick, einen Link in diesem Format zu setzen? Das würde mir ja schon langen.

Klar, ich könnte in die Seite diesen Link kloppen und sgen "Kopiere diesen Link in die Adressleiste" aber wir wollen ja der Faulheit ihren Tribut zollen und nur draufklicken

[geloescht_JesterDay]

Auf

http://BLUBNT03.firma.tld/Ordner/File.ext

Liefert FF wie IE folgendes:

[...]

Liegt in irgendeiner Form also am Server. Sieht mir nicht aus, wie eine Default Fehlermeldung der beiden.

Und das meinte ich ja... was liefert der Server an den FF. Nicht die Fehlermeldung die dann angezeigt wird... Die HTTP-Header.

[PieDie]

http://BLUBNT03.firma.tld/Ordner/File.ext

GET /Ordner/File.ext HTTP/1.1

Host: blubnt03.firma.tld

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Proxy-Connection: keep-alive

Referer: http://bla.firma.tld/navigation.php

HTTP/1.x 200 OK

Content-Type: text/html

Content-Length: 579

X-Cache: MISS from einserver.firma.tld

X-Cache-Lookup: MISS from einserver.firma.tld:3128

Proxy-Connection: keep-alive

----------------------------------------------------------

Kannst Du damit was anfangen? Mir sagt das so nix...

[Amstelchen]

HTTP/1.x 200 OK heisst, dass die datei am server vorhanden ist, die anfrage bearbeitet und der inhalt der datei an den client versendet wurde.

mir ist nicht ganz klar - und das geht aus den postings IMO nicht hervor - ob die datei jetzt via HTTP oder SMB transportiert werden soll; also im endeffekt als lokale datei über der netzwerkumgebung oder via webserversoftware transportiert werden soll.

welchen inhalt hat die datei - ist da aktiver inhalt drin, den FF verweigert? welchen dateityp hat die datei Datei.ext jetzt konkret.

s'Amstel

[PieDie]

Das ist eine Crystal Reports-Datei. Endung: .rpt

Warum sollte FF das blocken, wenn es doch über \\blabla funktioniert?

Die Datei ist freigegeben als \\BLUBNT03\Ordner\File.rpt

Wahrscheinlich ist das mein Logikfehler -> FireFox fühlt sich veralbert, einen SMB-Pfad als http:// verpackt vorgesetzt zu bekommen und vermag damit nichts anzufangen. (Was ist eigentlich der Unterschied zwischen http:// und file:// ? Welches Protokoll verwendet file// ?)

Der IE ist wohl so eng mit Windows verzahnt, dass er das erkennt, und entsprechend reagiert.

Sehe ich das richtig?

EDIT:

Ich hab mich mal durch die Ordnerstruktur gewuselt und den "echten" Dateipfad heausgesucht.

Damit bekomme ich die Fehlermeldung, die ich oben gepostet hab.

[geloescht_JesterDay]

Das ist eine Crystal Reports-Datei. Endung: .rpt

Warum sollte FF das blocken, wenn es doch über \\blabla funktioniert?

HTTP/1.x 200 OK

Content-Type: text/html

Content-Length: 579

Zum einen bedeutet 200 OK, dass der Server die Datei gefunden hat. Das ist aber nicht das entscheidende hier. Der Content-Type der gesendet wird, sagt dem Client was da für eine Datei kommt, in dem fall eine html-Datei. Eine Crystal Reports Datei ist aber wohl keine html-Datei, oder?

Wenn die Crystal Report Datei auch 579 byte groß ist, liefert er zumindest die richtige.

[PieDie]

Wow, danke schonmal für die Ausführliche Antwort

Über die file:// oder file:/// Geschichte werden keinerlei header-Daten abgefangen, von diesem live-http-Gedingens.

Ganz egal, ob ich nun den echten Pfad (BLUBNT03/d($)/Ornder/File.rpt) oder den freigegebenen nehme. FireFox ignoriert die file-Geschichte vollends.

Die Datei, ist wohl ein Binärfile, denke ich. Keine Ahnung, was genau das ist.

Ich bin mit meinem Latein am ende. Schnauze voll.

Ich werde versuchen, den "verantworlichen"/verantwortungslosen -.- dazu zu bringen, die erzeugten rtp-Files auf dem Rechner zu erstellen/kopieren/whatever, sodass man von dort aus zugreifen kann. Das geht nämlich klaglos. *hrmpf*

BTW:

Das Viech, wo die Files liegen, ist eine NT4 Maschine. Und der Aufruf http://BLUBNT03 bringt eine Art intranetseite zum Vorschein. Also macht das Ding sowohl einen auf Webserver als auch Fileserver.

Auf besagter Intranetseite wird übrgiens auch auf diese Files verlinkt und siehe da: IE geht, FF nicht.

[geloescht_JesterDay]

Über die file:// oder file:/// Geschichte werden keinerlei header-Daten abgefangen, von diesem live-http-Gedingens.

Ja, sagte ich ja.FF stellt nämlich in dem Fall eine Anfrage an das OS des REchners auf dem er läuft und da geht nix über HTTP o.ä. In dem Fall ist der FF nur eine Erweiterung des Windows-Explorers (in deinem Fall).

[PieDie]

hmm ok.

Kann man eigentlich einen Link folgenden Formats "erzwingen"? Also einer, den man anklicken kann, aber dennoch so aussieht:

\\BLUBNT03\Ordner\File.ext

Das machen ja beide Browser klaglos.

Prinzipiell ist da Thema aber abgekaut. Diese rtp-Files lesen Daten aus einer Datenbank und schreiben praktisch in sich selber, so wie ichd as verstehe.

Man kann schlicht die Dateien auf einen Webserver kopieren, und sie dort ganz geschmeidig per http:// aufrufen. Jetzt muss in den Viechern nur noch der richtige DB-Server eingetragen werden:floet:

Danke für Eure Hilfe (speziell JesterDay :e@sy )