prüfen, ob Datei auf Webserver existiert

[Lammi]

Tach zusammen,

wie kann ich mit JSP prüfen, ob auf einem anderen Webserver eine Datei existiert? isFile() funktioniert ja nicht mit http.

Danke schon mal!

[Lammi]

Tach zusammen,

wie kann ich mit JSP prüfen, ob auf einem anderen Webserver eine Datei existiert? isFile() funktioniert ja nicht mit http.

Danke schon mal!

isFile sollte natürlich File heissen.

[Alexander (HH)]

Moin Moin!

Gar nicht. Du kannst überprüfen, ob eine Resource existiert oder nicht. HTTP bietet dafür den HEAD-Request, der bei einer nicht existierenden Resource den Status-Code 404 zurückgibt. Einige andere Status-Codes sind auch noch zu berücksichtigen, z.B. die diversen 3xx-Codes für umgezogene Resourcen oder 410 für eine endgültig "weggezogene" Resource.

Alexander

[suit]

HTTP bietet dafür den HEAD-Request, der bei einer nicht existierenden Resource den Status-Code 404 zurückgibt.

Sofern der Webserver den richtigen Status ausspuckt - es gibt immer wieder Helden die bei einer nicht gefundenen Ressource mittels 200 OK die Startseite ausspucken :)

410 für eine endgültig "weggezogene" Resource.

410 ist nicht "weggezogen" sonder "überhaupt nicht mehr vorhanden".

Leider wirds mit 404 und 410 nicht so genau genommen und ersteres leider sehr oft statt zweiterem verwendet.

[Cheatah]

Hi,

»» 410 für eine endgültig "weggezogene" Resource.
410 ist nicht "weggezogen" sonder "überhaupt nicht mehr vorhanden".

stimmt. Für "endgültig weggezogen" gibt es die 110.

Cheatah, SCNR

[hotti]

hi,

stimmt. Für "endgültig weggezogen" gibt es die 110.

Oder die gleichnamige Fernsehserie mit vielen Beispielen um das "Warum".

So, das konnte ich mir nun nicht mehr verkneifen, zu Deinem Post, über den ich bereits heute mittag herzlich grinsen musste ;-)

Hotte

[Alexander (HH)]

Moin Moin!

»» HTTP bietet dafür den HEAD-Request, der bei einer nicht existierenden Resource den Status-Code 404 zurückgibt.
Sofern der Webserver den richtigen Status ausspuckt - es gibt immer wieder Helden die bei einer nicht gefundenen Ressource mittels 200 OK die Startseite ausspucken :)

Oh ja, von der Sorte kenne ich auch einige. Mein aktueller Held: Ein Dokumenten-Management-System (mit 1000 anderen Funktionen), das selbst bei eingeäscherter Datenbank und brennendem Server erstmal fröhlich "200 OK" in die Welt hinausposaunt, nur um anschließend ein "Uh, Mami, mir geht's nicht gut" abzulassen. (OK, der Originaltext ist leicht anders, aber ähnlich hilfreich.) Für so ein System einen Loadbalancer zu bauen, macht echt Spaß! ;-)

Alexander

[Tom]

Hello,

Oh ja, von der Sorte kenne ich auch einige. Mein aktueller Held: Ein Dokumenten-Management-System (mit 1000 anderen Funktionen), das selbst bei eingeäscherter Datenbank und brennendem Server erstmal fröhlich "200 OK" in die Welt hinausposaunt, nur um anschließend ein "Uh, Mami, mir geht's nicht gut" abzulassen. (OK, der Originaltext ist leicht anders, aber ähnlich hilfreich.) Für so ein System einen Loadbalancer zu bauen, macht echt Spaß! ;-)

Na, dann lass doch gleich nochmal ab, wie man es richtig macht.
Mit richtigem Status und trotzdem im Design der Seite...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Alexander (HH)]

Moin Moin!

Na, dann lass doch gleich nochmal ab, wie man es richtig macht.
Mit richtigem Status und trotzdem im Design der Seite...

Nun, in dem Fall relativ einfach: Wenn der Loadbalancer merkt, dass alle Server die Beinchen in die Luft halten und sich nicht mehr bewegen, werden alle Requests auf einen Webserver im Loadbalancer umgeleitet, der im besten Corporate Design und Corporate Language mitteilt, dass das zuständige Team gerade mit Herzmassagen an den Servern beschäftigt ist und alles bald wieder gut wird.

Wenn "nur" die URL falsch ist, kann z.B. der große alte Indianer ein komplett durchgestyltes Dokument ausliefern, man muß ihn nur darum bitten.

Ganz konkret bei dieser Anwendung KÖNNTE bei Problemen zwischen dem vermittelnden CGI-Programm und dem eigentlichen Anwendungsserver das CGI auch von sich aus eine von mehreren vorbereiteten, lokalen Dateien mit passendem HTTP-Status ausliefern. Das haben die Entwickler aber gründlich versäumt.

(Eine kleine Randnotiz zur Architektur des Systems: Das CGI ist ein wirklich kleines, offenbar in C geschriebenes Programm, dass kaum mehr macht als einen eingehenden Request an den als Service/Daemon laufenden Anwendungsserver weiterzureichen und die Antwort via Webserver zum Browser zurückzutrommeln - also ein echtes Gateway. Für einige auserwählte Webserver gibt es auch ein direkt im Webserver laufendes Modul, dass den gleichen Job von innerhalb des Webservers erledigt - natürlich nur gegen viel Extra-Kohle für die kommerziellen Webserver. Die Lösung mit dem CGI ist aber schnell genug, bremsender Faktor ist definitiv der Anwendungsserver.)

Alexander

[Tom]

Hello,

[...]

es ist doch aber häufig so, dass ein (selbstgeschriebenes) "CMS" merkt, dass eine angeforderte Ressource nicht vorhanden ist. Wie soll man da reagieren?

Bitte mal mit möglichst wenig Ironie und sonstigen ablenkenden Stilmitteln:

...

:-)

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Alexander (HH)]

Moin Moin!

es ist doch aber häufig so, dass ein (selbstgeschriebenes) "CMS" merkt, dass eine angeforderte Ressource nicht vorhanden ist. Wie soll man da reagieren?

Bitte mal mit möglichst wenig Ironie und sonstigen ablenkenden Stilmitteln:

Sinngemäß:

  
# Pseudocode-Perl-Mix, CGI-Environment:  
  
use CGI qw(...);  
  
# ...  
  
sub NotFound  
{  
    my $request=shift;  
    my $content;  
    eval {  
        $content=processTemplate(  
            'errors/not-found.template',  
            {  
                URI => $request->uri,  
            }  
        );  
    };  
    if ($@) {  
        warn "Processing errors/not-found.template: $@\n";  
        $content=join(  
            '',  
            start_html(  
                -title=>'404 Not Found',  
            ),  
            h1('404 Not Found'),  
            p(  
                'Could not find "',  
                escapeHTML($request->uri),  
                '". Additionally, an error was found while processing the "errors/not-found.template" file. See the web server\'s error log for details.'  
            ),  
            end_html(),  
        );  
    }  
    print  
        header(-status=>404),  
        $content;  
    exit;  
}  
  
# ...  
  
    if (resourceFound($request)) {  
        # ...  
    } else {  
        NotFound($request);  
    }  
  
# ...  
  

Das läßt sich natürlich noch verfeinern, z.B. mit Fehlermeldungen in der konfigurierten bzw. in der Session ausgewählten Sprache. Auch größere Katastrophen, die typischerweise in einem 500 enden, lassen sich mit einem eval { BLOCK } rund um das Script abfangen. (Wer auf Java steht, liest hier bitte try-catch.)

Wer einen DB-Ausfall genauer spezifizieren möchte, könnte in dem Fall z.B. mit Status "503 Service Unavailable" antworten statt mit "500 Internal Server Error".

Für Resourcen, die irgendwann mal existiert haben, aber unter der angeforderten URL auf absehbaree Zeit nicht wieder existieren werden, sollte man "410 Gone" statt "404 Not Found" liefern, wenn das CMS diese Information hat. Für eine Stellenausschreibung einer wieder besetzen Stelle wäre das beispielsweise sinnvoll.

Alexander