[Allegro] Re: [allegro-OEB] open/get mit http://-URL

[Anando Eger]

Hallo Herr Berger, Liebe Listenleserinnen und -leser,

ich glaube, dass die ganze Diskussion hier am Ziel vorbeiging.

Meine Ausgangsfrage war, ob sich "weniger" (keine automatische 
Verfolgung von Redirects), und nicht "mehr" (nachträgliche Korrektur
erfolgter Auflösung von Verweisen) in Bezug auf das Verhalten
von 'open' oder 'get I' realisieren ließe.

Aus der Beschreibung der betroffenen Flexbefehle könnte man nur
bei sehr viel gutem Willen, z.B. aus dem Bezug auf den "Browser"
und der entsprechenden Systemkenntnis, erkennen, dass eine 
automatische Verweisauflösung erfolgen könnte. Ich habe eher den
Eindruck gewonnen, dass eine Behandlung "wie bei einer lokalen Datei"
beschrieben wird.

Herr Lackhoff hat den Kern ja schon getroffen, mehr ist dazu 
meiner Meinung nach nicht zu sagen.

Eine Frage bleibt für mich aber offen: Für welchen Anwendungsfall
ist dann 'open'/get I' sinnvoll? Wann stört es _nicht_, wenn 
kommentarlos eine andere als die angeforderte Datei geliefert wird?
Wir reden hier ja _nicht_ von interaktivem browsing! (z.B. janas)
 
Herr Berger, Sie nahmen immer wieder auf die Servereinstellungen 
Bezug: Ist es nicht besser, auf 'Magie' zu gleich verzichten als 
sie später wieder mit Gegenmaßnahmen zu neutralisieren?
Wenn ich über 'get' den Text der 301-Meldung erhielte, könnte ich
selbst entscheiden, ob ich dem Verweis folgen möchte oder nicht.

Viele Grüße
Anando Eger

---------------------------------------------------------------------
Anando Eger Datenverarbeitung
Herr Dipl.-Ing. Anando Eger
Gustav-Voigt-Str. 24
01156 Dresden
Tel.: +49 (0)351 454 1236  http://www.aneg-dv.de
Fax: +49 (0)351 454 1238  mailto:a.eger at aneg-dv.de
---------------------------------------------------------------------




On 25 Feb 2011 at 9:07, Thomas Berger wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Lieber Herr Eger,
> 
> >> Herrn Egers Server sagt: "Diese[!] Ressource ist jetzt (permanent) als
> >> test_123.txt zu finden" und a99 verhaelt sich entsprechend (dass ein
> >> Linkchecker hier eine tiefergehendere Analyse benoetigt als ein "normaler"
> >> Client ist natuerlich klar, steht aber nicht im Widerspruch dazu, dass sich a99
> >> "korrekt" verhaelt).
> >>
> >> Herr Eger hingegen findet, das sei aber nicht die ~gemeinte~ Ressource, denn
> >> die gaebe es ja schliesslich gar nicht.
> > 
> > 1. "Herr Egers Server" ist ein 1und1-Server mit unveränderten Standardeinstellungen,
> >    steht also einfach als Beispiel für jede Menge anderer Server
> 
> o.k.
> 
> > 2. Was ist gewünscht? Die geforderte Datei zu lesen oder bei open ein
> >    "no" zu erhalten
> 
> siehe unten: Serverseitig realisiert ist genau das Gegenteil dieses Wunsches
> 
> > 3. Es ist also aus Sicht des a99-Einsatzes _nicht_ sinnvoll, http-Statusmeldungen
> >    intern automatisch auszuwerten. 
> 
> das tut ja Windows bereits. Und ich wuerde sagen, dass a99 (bzw. das "get" in
> der Flexsprache) keine sonderlich spezialisierte Rolle als HTTP-Client
> annimmt und daher das vorgegebene Standardverhalten vorzuziehen ist.
> 
> Ausserdem ist das Beispiel ja auch leicht pathologisch: Die Standardannahme
> scheint mir zu sein, dass es eine Ressource mit einer URL gegeben hat, die
> entweder umgezogen ist (HTTP-Spezifikation) oder mit Schreibfehler angefordert
> wird (mod_speling). Der Fall hier, wo unter einer ausgedachten URL eine
> Ressource anzufordert, die es nie gegeben hat, faellt da ziemlich heraus.
> Festzuhalten bleibt aber, dass der konkrete Webserver per Konfiguration
> angewiesen wurde, in jedem Fall eine vorhandene Datei zurueckzuliefern,
> damit es moeglichst nie zu einem Error "not found" kommt.
> 
> Die Alternative waere, in a99 eine Art Gegen-Internet zu implementieren,
> indem (in dem) HTTP-Statuscodes weitgehend ignoriert und durch eigene
> Theorien ueber die Befindlichkeit des Servers ersetzt werden. Gerade in
> legitimen Faellen von Weiterleitungen (z.B. jegliche Art von Resolving-
> Diensten, < http://daia.hebis.de/resolver/wikimedia/pndresolver/108172198 >
> vollzieht zunaechst drei temporaere Redirects) duerfte a99 sich dann schnell
> als unbenutzbar herausstellen.
> 
> Also: Man kann "korrektes" Verhalten fuer den HTTP-Status 4xx nur dann
> einfordern, wenn so ein Status auch geliefert wird. a99 ist nicht die
> Stelle, an der saemtliche Konfigurationspannen aller existierenden
> Webserver ausgebuegelt werden koennen (oder sollten).
> 
> viele Gruesse
> Thomas Berger
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iJwEAQECAAYFAk1nY1QACgkQYhMlmJ6W47M77QQAitKh5aM92r60JfMV4uqXwjIe
> Nbl2+qqYCtlcKX/eeDNzYVXvQLKD6NPdzUduUQ9WHirRQKIGuVeYCOsk8BCDmZ8P
> MI5kP09J4dvyqQKWs92bZ+52IRjAm4mG9GmNuJ8BPzZt5YmNQmWi4Vh89Yt20j+O
> Kn0cLE0I6cvYen3mnvc=
> =YM3e
> -----END PGP SIGNATURE-----
>