und es geht doch ! htaccess über formular

[Michael W.]

Hallo,

hätte ich auch nicht gedacht das das möglich ist, aber probiert mal euch ans forum anzumelden

http://forum.de.selfhtml.org/my/

dann kommt eine htaccess/htpasswd abfrage

versucht mal es mal so: < http://username:[e-mail]/my/>

bei mir hat es funktioniert (IE)

man brauch nur ein kleines javascript das die daten als location.href an den browser gibt als 'http://' + username + ':' + passwort + 'domain.de'

:-)

[Thomas J.S.]

HZallo,

hätte ich auch nicht gedacht das das möglich ist, aber probiert mal euch ans forum anzumelden

versucht mal es mal so: < http://username:[e-mail]/my/>

bei mir hat es funktioniert (IE)

Das funktioniert überall (und das ist keine Formularabfrage, sondern eine htaccess-abfrage), siehe dazu http://www.ietf.org/rfc/rfc2396.txt Punkt 3.2.2

Nachteil: in den Logfiles bleibt die Referenz-URI dann auch so erhalten "username:[e-mail]/my/".

Grüße
Thomas

[Sven Rautenberg]

Moin!

Das funktioniert überall (und das ist keine Formularabfrage, sondern eine htaccess-abfrage), siehe dazu http://www.ietf.org/rfc/rfc2396.txt Punkt 3.2.2

Zitat: "Some URL schemes use the format "user:password" in the userinfo
   field. This practice is NOT RECOMMENDED, because the passing of
   authentication information in clear text (such as URI) has proven to
   be a security risk in almost every case where it has been used."

Außerdem werden in diesem Dokument nur allgemein URLs beschrieben, nicht aber konkret HTTP.

In RFC 1738 http://www.ietf.org/rfc/rfc1738.txt heißt es nämlich:
Zitat: "   An HTTP URL takes the form:

http://<host>:<port>/<path>?<searchpart>

where <host> and <port> are as described in Section 3.1. If :<port>
   is omitted, the port defaults to 80.  No user name or password is
   allowed.  <path> is an HTTP selector, and <searchpart> is a query
   string. The <path> is optional, as is the <searchpart> and its
   preceding "?". If neither <path> nor <searchpart> is present, the "/"
   may also be omitted."

Im gleichen Dokument wird für FTP-URLs die Angabe von Usernamen und Passwort explizit erlaubt. Es ist also wirklich eine Spezialität der HTTP-URL. Dass Browser die Verhaltensweise von FTP-URLs übernommen haben, macht es ja gerade so schwierig, weil es eben nicht vorausgesetzt werden darf. Außerdem ist es wahrscheinlich ein Sicherheitsproblem, wenn Usernamen und Passwörter öffentlich in Links auftauchen.

Es mag sein, dass eine spätere RFC diese Definition abändert - ich habe aber keine RFC gefunden, die sich ebenfalls um URLs und HTTP kümmert.

Nachteil: in den Logfiles bleibt die Referenz-URI dann auch so erhalten "username:[e-mail]/my/".

Nein, das nun gerade nicht. Der _Browser_ setzt die Authentifizierungsangaben um in entsprechende HTTP-Header und merkt sich die Angaben, während er sie aus der URL entfernt. Der Server kann bei Falschangaben immer noch 401 zurücksenden (was das Authentifizierungsfeld wieder auf den Plan ruft - also ist die Formularlösung doch keine echte Lösung, weil Falscheingaben wieder zu einem "undesignten" Eingabefeld führen - und vermutlich zu Benutzerverwirrung), und er wird den Usernamen in den Logfiles im entsprechenden Feld aufführen, falls entsprechend konfiguriert (default-Einstellung beim Apache ist es jedenfalls).

[Thomas J.S.]

Hallo Sven,

Das funktioniert überall (und das ist keine Formularabfrage, sondern eine htaccess-abfrage), siehe dazu http://www.ietf.org/rfc/rfc2396.txt Punkt 3.2.2

Zitat: "Some URL schemes use the format "user:password" in the userinfo
   field. This practice is NOT RECOMMENDED,

Ich habe ja darauf hingewiesen, dass es nicht zu empfehlen ist.

» In RFC 1738 http://www.ietf.org/rfc/rfc1738.txt heißt es nämlich:

Bitte Punkt "3.1. Common Internet Scheme Syntax" lesen.

Grüße
Thomas

[Michael W.]

Nachteil: in den Logfiles bleibt die Referenz-URI dann auch so erhalten "username:[e-mail]/my/".

dadrauf habe ich gewartet:
du kannst doch auf der folgeseite eine umleitung einrichten dann dürfte der es wegsein !

[Christian Kruse]

Hallo Michael,

Nachteil: in den Logfiles bleibt die Referenz-URI dann
auch so erhalten
"username:[e-mail]/my/".

dadrauf habe ich gewartet:
du kannst doch auf der folgeseite eine umleitung einrichten
dann dürfte der es wegsein !

Wohl kaum ;) Die Logfiles aendern sich sicher nicht, nur weil
du einen 302-Header schickst. Und es aendert immer noch nichts
daran, dass eine solche URI bei HTTP *verboten* ist.

Gruesse,
 CK

[molily]

Hallo, Christian,

Nachteil: in den Logfiles bleibt die Referenz-URI dann
auch so erhalten
"username:[e-mail]/my/".

Das ist, wie schon einige gesagt haben, unwahr.
Wäre auch zu pervers, wenn die Anfrage plötzlich
  GET username:passwort@/my/ HTTP/1.1
oder ähnlich lauten würde. :)

dadrauf habe ich gewartet:
du kannst doch auf der folgeseite eine umleitung einrichten
dann dürfte der es wegsein !

Wohl kaum ;) Die Logfiles aendern sich sicher nicht, nur weil
du einen 302-Header schickst.

Was hat das Problem eigentlich mit den Server-Logfiles zu tun?
Meiner Meinung nach gar nichts, dort wird so oder so der Benutzername geloggt, oder auch nicht, je nachdem wie der Admin Apaches(/$httpd's) Logformat eingestellt hat.

Und es aendert immer noch nichts
daran, dass eine solche URI bei HTTP *verboten* ist.

Prinzipienreiter. ;)
Bitte lesen: [pref:t=29154&m=157748], ab "Für die lokale, eigene Anwendung hingegen ..."
Um nichts anderes ging es hier - wieso sollte ich öffentlich einen /my/-Link mit meinen Zugangsdaten setzen?
Hast du dagegen etwas substanzvolleres einzuwenden als "es ist nicht erlaubt, deswegen ist es böse[tm]"? Entsteht nicht das Gesetz aus der Moral, und nicht umgekehrt?[tm] :)
Auf den von mir verwendeten Browsern funktioniert es (okay, Lynx und w3m nicht, aber das kann ich verkraften, allzu schreibfaul bin ich nicht, dass mich das Eintippen in diesem Fall stören würde, falls /my/ überhaupt sein muss), und da es für den Server keinen Unterschied macht (ach nein, es spart sogar Traffic, denn die 401-Seite wird überflüssig), verwende ich es.
So what? ;)

Grüße,
Mathias

[Christian Seiler]

Hallo Mathias,

Grmpf - Vorschaufunktion - jetzt hab' ich mein Tab geschlossen, ohne noch mal abzuschicken.

Nachteil: in den Logfiles bleibt die Referenz-URI dann
auch so erhalten
"username:[e-mail]/my/".

Das ist, wie schon einige gesagt haben, unwahr.

Dir ist klar, dass CK mit Referenz-URI den Referer meint?

Wäre auch zu pervers, wenn die Anfrage plötzlich
  GET username:passwort@/my/ HTTP/1.1
oder ähnlich lauten würde. :)

Nö. Bei Mozilla sähe das so aus:

GET /my/ HTTP/1.1
Host: forum.de.selfhtml.org
Connection: Keep-Alive
irgendwas...

antwort

GET /my/?m=1&t=1 HTTP/1.1
Host: forum.de.selfhtml.org
Connection: Close
Referer: http://username:[e-mail]/my/
irgendwas...

ntwort

Bei Lynx:

GET /my/ HTTP/1.1
Host: username:[e-mail]
irgendwas...

fehler-meldung

Was hat das Problem eigentlich mit den Server-Logfiles zu tun?
Meiner Meinung nach gar nichts, dort wird so oder so der Benutzername geloggt, oder auch nicht, je nachdem wie der Admin Apaches(/$httpd's) Logformat eingestellt hat.

Username: ja, Passwort: nein.

Prinzipienreiter. ;)

Du setzt Dich doch auch für Prinzipien ein. ;-P

Hast du dagegen etwas substanzvolleres einzuwenden als "es ist nicht erlaubt, deswegen ist es böse[tm]"? Entsteht nicht das Gesetz aus der Moral, und nicht umgekehrt?[tm] :)

Was hat das mit Moral zu tun? Das hat etwas mit der HTTP-Spec zu tun. Du kannst gerne HTTP/1.2 oder HTTP/2.0 entwerfen. ;)

Grüße,

Christian

P.S.: wget bietet 2 Kommandozeilenoptionen für Benutzername und Passwort an. Damit kann man mit nur einer Zeile eine URI anfordern und ist desweiteren noch HTTP-konform. Wenn das mal kein Fortschritt ist. *ätsch* ;-P

[Henryk Plötz]

Moin,

Nö. Bei Mozilla sähe das so aus:

Doppel-Nö, bei Mozilla _sieht_ das so aus:

GET /my/ HTTP/1.1
...

HTTP/1.0 401 Unauthorized
...

GET /my/ HTTP/1.1
...
Authorization: Basic ...

HTTP/1.0 200 OK
...

GET /src/forum.css HTTP/1.1
...
Referer: http://forum.de.selfhtml.org/my/

Zwei Sachen werden deutlich: a) die anfängliche 401-Meldung ist nicht eingespart wie anderswo in diesem Thread behauptet, b) der Referer ist sauber.

(Innerlich bin ich natürlich schockiert, daß Mozilla sowas überhaupt erlaubt.)

--
Henryk Plötz
Grüße aus Berlin

[Christian Seiler]

Hallo Henryk,

Zwei Sachen werden deutlich: a) die anfängliche 401-Meldung ist nicht eingespart wie anderswo in diesem Thread behauptet, b) der Referer ist sauber.

Waaaaaaaaaaaaaas? Das hat nicht mal den Referer-Nachteil? ARRRGH! Dann ist ja das Haupt-Kontra-Argument vom Tisch. Wenigstens doch noch ein Nachteil mehr... (401er)

(Innerlich bin ich natürlich schockiert, daß Mozilla sowas überhaupt erlaubt.)

Ebenso.

Grüße,

Christian

[Christian Kruse]

Hallo Henryk,

Doppel-Nö, bei Mozilla _sieht_ das so aus:

GET /my/ HTTP/1.1
...

HTTP/1.0 401 Unauthorized
...

GET /my/ HTTP/1.1
...
Authorization: Basic ...

HTTP/1.0 200 OK
...

GET /src/forum.css HTTP/1.1
...
Referer: http://forum.de.selfhtml.org/my/

Noe. Bei mir sieht das so aus:

GET /my/ HTTP/1.1
...

HTTP/1.0 401 Unauthorized
...

GET /my/ HTTP/1.1
Authorization: Basic ...
...
Referer: http://user:[e-mail]/my/
...

HTTP/1.0 200 Ok

Die Logfiles bestaetigen das. Die Mozilla-Version ist
irgendeine kurz vor 1.0, aus dem CVS.

Zwei Sachen werden deutlich: a) die anfängliche
401-Meldung ist nicht eingespart wie anderswo in diesem
Thread behauptet,

ACK.

b) der Referer ist sauber.

NACK.

Gruesse,
 CK

[Henryk Plötz]

Moin,

Die Logfiles bestaetigen das. Die Mozilla-Version ist
irgendeine kurz vor 1.0, aus dem CVS.

Meine ist 1.0.1 und macht das nicht, also haben die doch tatsächlich eine Funktion gefixt die gar nicht da sein sollte: erschütternd.

Nebenbei zeigt es aber sehr schön, wie unzuverlässig - da nicht standardisiert bzw. vom Standard verboten - diese Vorgehensweise ist.

--
Henryk Plötz
Grüße aus Berlin

[Christian Kruse]

Hallo Henryk,

das muss jetzt sein:

Nebenbei zeigt es aber sehr schön, wie unzuverlässig - da
nicht standardisiert bzw. vom Standard verboten - diese
Vorgehensweise ist.

Full ACK.

Gruesse,
 CK

[molily]

Hallo, Henryk,

Die Logfiles bestaetigen das. Die Mozilla-Version ist
irgendeine kurz vor 1.0, aus dem CVS.

Meine ist 1.0.1 und macht das nicht, also haben die doch tatsächlich eine Funktion gefixt die gar nicht da sein sollte: erschütternd.

Möglicherweise haben andere Menschen andere Ansichten darüber.

Nebenbei zeigt es aber sehr schön, wie unzuverlässig - da nicht standardisiert bzw. vom Standard verboten - diese Vorgehensweise ist.

Wo ist da das Argument? Wenn die Mozilla-Leuts es nicht schaffen, eine laut dem hochheiligen Standard unerlaubtes, aber von den meisten großen Browsern "geduldeten" Quasistandard fehlerfrei einzubauen (...und damit neu zu erfinden, weil es eben keinen Standard gibt), ändert das nichts daran, dass andere bedeutende Browser solche aberwitzigen Fehler nicht beinhalten (und das schon seit Jahren, dass Mozilla es erst... ähm, vielleicht 5 oder 6 Jahre später schafft, ist nichts als lachhaft).

Das Fehlverhalten alter Mozillas ist eine klare Sicherheitslücke, die nichts damit zu tun hat, dass es ein nicht standardisiertes Feature ist. Dein Kommentar hört sich so an, als wolltest du implizit sagen: "Wenn Browserntwickler eigenständig Erweiterungen einbauen, können nur schlechte und unsichere Lösungen herauskommen. Wenn hingegen alles durchstandardisiert ist und die Browserentwickler den Standards haargenau folgen, ist die Software in jedem Fall besser."

Wo bitte ist das Sicherheitsproblem von HTTP-URLs mit Logindaten? Ich bin kein bisschen schlauer.
Erstens verwende ich keine Browser, die die Zugangsdaten im Referer senden würden. Zweitens verwende ich keine Browser, die überhaupt Referer senden. Drittens würde ich alles filtern, was auch nur irgendwie nach einem Referer-Header riecht.
Ich sehe immer noch kein Grund, wieso ich es nicht verwenden sollte. Die Browser (meine *Benutzeragenten*) erlauben mir diese Erleichterung und ich nutze sie. Findest du sicher erschütternd. ;)

Grüße,
Mathias

[Christian Kruse]

Hallo molily,

Das ist, wie schon einige gesagt haben, unwahr.
Wäre auch zu pervers, wenn die Anfrage plötzlich
  GET username:passwort@/my/ HTTP/1.1
oder ähnlich lauten würde. :)

Noe, das ist durchaus wahr. Betrachte mal den Referer-Header.

Was hat das Problem eigentlich mit den Server-Logfiles zu
tun?

Da wird dein Passwort und dein Username drin stehen.

Meiner Meinung nach gar nichts, dort wird so oder so der
Benutzername geloggt, oder auch nicht, je nachdem wie der
Admin Apaches(/$httpd's) Logformat eingestellt hat.

Richtig, aber sicherlich nicht dass Passwort.

Und es aendert immer noch nichts
daran, dass eine solche URI bei HTTP *verboten* ist.

Prinzipienreiter. ;)

Nein. Es hat durchaus seine Gruende, warum das verboten ist.

Um nichts anderes ging es hier

Klar -- es ging generell um einen Link der oben beschriebenen
Form. Ich sehe nicht, wo Michael eine Einschraenkung gemacht
hat.

• wieso sollte ich öffentlich einen /my/-Link mit meinen
  Zugangsdaten setzen?

Das tust du automatisch damit.

Denkt daran, dass die Webalizer-Daten veroeffentlicht werden!
Da ist auch eine komplette Liste aller Referer dabei!

Gruesse,
 CK

[Sven Rautenberg]

Moin!

• wieso sollte ich öffentlich einen /my/-Link mit meinen
  Zugangsdaten setzen?

Das tust du automatisch damit.

Denkt daran, dass die Webalizer-Daten veroeffentlicht werden!
Da ist auch eine komplette Liste aller Referer dabei!

Das stimmt! Einfach mal http://webalizer.teamone.de/selfforum/ref_200211.htm besuchen und nach dem @-Zeichen suchen. Immerhin ein Eintrag ist dort zu finden - fürs Testforum, aber immerhin.

Und die Tatsache, dass der Referrer auf diese Weise öffentlich wird, ist leider viel zu wenig bekannt.

Natürlich ist der angerichtete Schaden eher gering. Man muß sich bei kompromittierten Accounts eventuell ein neues Passwort ausdenken, oder möglicherweise einen neuen Account registrieren - mehr schlimme Dinge sind derzeit nicht möglich, denn Benutzerauthentifizierung im eigentlichen Sinne wird hier ja nicht praktiziert. Aber bedenklich ist es schon, da manche dummen User ihr einziges Passwort bei allen Gelegenheiten verwenden: Systemanmeldung, Mailserver, FTP zum Webspace etc... Eine ganz schlechte Angewohnheit, aber wohl nicht auszurotten.

[AlexBausW]

Hallo,

Das ist, wie schon einige gesagt haben, unwahr.
Wäre auch zu pervers, wenn die Anfrage plötzlich
  GET username:passwort@/my/ HTTP/1.1
oder ähnlich lauten würde. :)

Noe, das ist durchaus wahr. Betrachte mal den Referer-Header.

Ich habe das mal mit einem Skript getestet, indem ich in einem geschützten Bereich mittels verbotener URL eingedrungen, und anschließend per Link von dort aus auf Skripte innerhalb und außerhalb des geschützten Bereichs gesprungen bin. In keinem Fall konnte ich mit meinem NN4.73 provozieren, daß die Zugangsdaten im HTTP_REFERER erscheinen.

Was hat das Problem eigentlich mit den Server-Logfiles zu
tun?

Da wird dein Passwort und dein Username drin stehen.

Zumindest mit dem NN4.73 aller wahrscheinlichkeit nach nicht. :)
Du könntest aber ja spaßeshalber mal in die Logfiles schauen, und die entsprechenden User, deren Daten dort ersichtlich sind anmailen, und sie so überzeugen, nicht verbotene URLs zu verwenden. :)

• wieso sollte ich öffentlich einen /my/-Link mit meinen
  Zugangsdaten setzen?

Das tust du automatisch damit.

Was aber imho nicht für alle Useragenten gleichermaßen gilt. Man könnte ja sogar einen lokalen Proxy damit beauftragen, solche "URLs" in die entsprechende Requestform umzuwandeln.

Denkt daran, dass die Webalizer-Daten veroeffentlicht werden!
Da ist auch eine komplette Liste aller Referer dabei!

Kann man sich das schon mal anschauen? (nichts Böses im Sinn habend, ehrlich, ich schwör's ;-)

Gruß Alex

[Christian Kruse]

Hallo Alex,

Du könntest aber ja spaßeshalber mal in die Logfiles
schauen, und die entsprechenden User, deren Daten dort
ersichtlich sind anmailen, und sie so überzeugen, nicht
verbotene URLs zu verwenden. :)

Als haett ich nicht schon genug zu tun ;)
Nene, da sollen die schoen selber drauf achten.

Was aber imho nicht für alle Useragenten gleichermaßen
gilt.

Natuerlich nicht. Wie wir bei Henryk gesehen haben gilt das
ja nichtmal fuer alle Versionen eines User-Agents.

Man könnte ja sogar einen lokalen Proxy damit beauftragen,
solche "URLs" in die entsprechende Requestform umzuwandeln.

Jups, durchaus.

Denkt daran, dass die Webalizer-Daten veroeffentlicht
werden! Da ist auch eine komplette Liste aller Referer
dabei!

Kann man sich das schon mal anschauen? (nichts Böses im
Sinn habend, ehrlich, ich schwör's ;-)

*g* Die Webalizer-Daten werden jede Nacht aktualisiert.

Gruesse,
 CK

[Michael W.]

Nachteil: in den Logfiles bleibt die Referenz-URI dann auch so erhalten "username:[e-mail]/my/".

nochwas:
< http://testuser:[e-mail]/test/> achte mal auf deine browser-adress-zeile da steht dann danach nur die domain (ist also ne server-einstellungs-sache)
zumindest war das eben bei mir so, könnte sein das es bei anderen browsern net funzt, dann wärs aber ne browser-einstellungs-sache - wäre aber auch schwachsinn, weil bei selfhtml bleibt das passwort in der uri stehen und bei meiner domain nicht ...

[Sven Rautenberg]

Moin!

hätte ich auch nicht gedacht das das möglich ist, aber probiert mal euch ans forum anzumelden

http://forum.de.selfhtml.org/my/

dann kommt eine htaccess/htpasswd abfrage

versucht mal es mal so: < http://username:[e-mail]/my/>

bei mir hat es funktioniert (IE)

Deine Entdeckung ist nicht neu. Sie ist aber sehr krititisch zu betrachten.

Zum einen: Die Angabe eines Passwortes in HTTP-URLs ist in keinem Standard enthalten (wohl aber der Username). Es ist daher davon abzuraten, sich auf das
Funktionieren dieses Quasi-Standards zu verlassen - es muß nicht funktionieren! Für Anwendungen, die für alle Benutzer erreichbar sein sollen, ist das ein K.O.-Kriterium.

Für die lokale, eigene Anwendung hingegen ist es durchaus eine erlaubte Erleichterung: Da benutzt man üblicherweise einen, zwei oder drei konkrete Browser, mit denen man das Funktionieren kurz testen kann - und benutzt es dann einfach weiter.

man brauch nur ein kleines javascript das die daten als location.href an den browser gibt als 'http://' + username + ':' + passwort + 'domain.de'

Warum so kompliziert? Das einzige, was die Benutzeranmeldung erleichtert bzw. ermöglicht, ist die benutzerspezifische Ansicht - es ist damit aber keinerlei Authentifizierung verbunden. Also sind die Anmeldedaten eher einer geringen Sicherheitsstufe zuzuordnen - und es spricht absolut nichts dagegen, den kompletten Link zum my-Forum z.B. in die eigenen Bookmarks zu setzen, ganz ohne Javascript. :)

[MudGuard]

Hi,

Zum einen: Die Angabe eines Passwortes in HTTP-URLs ist in keinem Standard enthalten (wohl aber der Username).

Zitat aus RFC 1738 (URLs), Abschnitt 3.3 HTTP-URLs (http://www.ietf.org/rfc/rfc1738.txt):

No user name or password is allowed.

cu,
Andreas

[Michael W.]

Warum so kompliziert? Das einzige, was die Benutzeranmeldung erleichtert bzw. ermöglicht, ist die benutzerspezifische Ansicht - es ist damit aber keinerlei Authentifizierung verbunden. Also sind die Anmeldedaten eher einer geringen Sicherheitsstufe zuzuordnen - und es spricht absolut nichts dagegen, den kompletten Link zum my-Forum z.B. in die eigenen Bookmarks zu setzen, ganz ohne Javascript. :)

mit dem formular sollte doch nur ein anwendungsbeispiel dargestellt werden. klar mache ich das über die linkliste "links"!

[$xNeTworKx]

Hi,

hätte ich auch nicht gedacht das das möglich ist, aber probiert mal euch ans forum anzumelden

http://forum.de.selfhtml.org/my/

dann kommt eine htaccess/htpasswd abfrage

versucht mal es mal so: < http://username:[e-mail]/my/>

bei mir hat es funktioniert (IE)

man brauch nur ein kleines javascript das die daten als location.href an den browser gibt als 'http://' + username + ':' + passwort + 'domain.de'

Sorry, das verstehe ich irgendwie nicht =). Soll das heißen, dass ein .htaccess Passwortschutz sozusagen leicht zu umgehen ist, oder wie muss man das jetzt verstehen ?

$xNeTworKx.

[Thomas J.S.]

Hallo,

Sorry, das verstehe ich irgendwie nicht =). Soll das heißen, dass ein .htaccess Passwortschutz sozusagen leicht zu umgehen ist, oder wie muss man das jetzt verstehen ?

Du muss es so verstehen, dass es icht unbedingt nötig ist, sich über die htaccess-Abfrage anzumelden, da Benutzernamen und Passwort bereits im URI der geschützten Seite eingetragen werden können.

Grüße
Thomas

[Sven Rautenberg]

Moin!

Sorry, das verstehe ich irgendwie nicht =). Soll das heißen, dass ein .htaccess Passwortschutz sozusagen leicht zu umgehen ist, oder wie muss man das jetzt verstehen ?

Du muss es so verstehen, dass es icht unbedingt nötig ist, sich über die htaccess-Abfrage anzumelden, da Benutzernamen und Passwort bereits im URI der geschützten Seite eingetragen werden können.

»»
Also, mit Lynx funktioniert das nicht. Um nur mal ein Beispiel zu nennen für einen Browser, der durchaus Verwendung findet.

[Thomas J.S.]

Hallo Sven

»»
Also, mit Lynx funktioniert das nicht. Um nur mal ein Beispiel zu nennen für einen Browser, der durchaus Verwendung findet.

Das ist wohl kaum mein Fehler ;-)

Grüße
Thomas

[Andreas Korthaus]

Hallo!

Also, mit Lynx funktioniert das nicht. Um nur mal ein Beispiel zu nennen für einen Browser, der durchaus Verwendung findet.

Das mag ein Argument sein für Seiten mit einem Lynx Anteil von mehr als 0,1%, also für die wenigsten Seiten. Mich wü+rde da eher stören, das irgendwelche bekannteren Browser das in Zukunft evtl nicht mehr können!

Grüße
Andreas