"User-Agent" vom Header oder navigator.userAgent?

[lsfr77]

Hallo ihr Experten ;),

es wäre nett, wenn mir jemand von euch die im Betreff gestellte Frage beantworten könnte. Um genauer zu verstehen, worum es in der Frage geht, bitte ich euch, zuallererst einmal folgendes PHP-Skript anzusehen:

  
<?php  
echo "User-Agent Header: ".$_SERVER['HTTP_USER_AGENT']."<br>";  
echo "User-Agent JavaScript: <script>document.write(navigator.userAgent)</script>";  
?>  

Wir ihr sehen könnt, gibt das Skript zuerst den vom Client an den Server gesendeten User-Agent-Wert des Headers und dann das dazugehörige JavaScript-Pendant (navigator.userAgent) aus.

Die beiden zurückgegebenen User-Agents sollten doch eigentlich immer gleich lauten, oder? Schließlich dürfte es doch keinen Unterschied machen, ob man den User-Agent client- oder serverseitig abfragt.

Umso verwunderter war ich dann, als ich meinen Browser testweise einen manipulierten Header-User-Agent senden ließ (Erweiterung "Modify Headers" unter Google Chrome); die Header-Variante zeigte brav den "gefälschten" Header an, während sich die "navigator.userAgent"-Ausgabe nicht verändert hatte, also  immer noch den Standard-User-Agent meines Browsers [der da wäre: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1] anzeigte.

Muss ich daraus den Schluss ziehen, dass die beiden User-Agents grundsätzlich verschiedene Informationen liefern?

Wenn ja, warum ist das so?

Wäre es dann nicht klüger, immer nur navigator.userAgent abzufragen, da dabei anscheinend stets der "richtige" User-Agent zurückgegeben wird, auch wenn ein manipulierter Header-User-Agent gesendet wird?
(Google jedenfalls wechselt beim Header-User-Agent-Wert "test" in eine Art Kombitabilitätsansicht, scheint sich also (zu Unrecht?) (nur) auf die serverseitige Abfrage zu verlassen ...)

LG LSFR77

[dedlfix]

Tach!

Umso verwunderter war ich dann, als ich meinen Browser testweise einen manipulierten Header-User-Agent senden ließ (Erweiterung "Modify Headers" unter Google Chrome); die Header-Variante zeigte brav den "gefälschten" Header an, während sich die "navigator.userAgent"-Ausgabe nicht verändert hatte, also  immer noch den Standard-User-Agent meines Browsers [der da wäre: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1] anzeigte.

Muss ich daraus den Schluss ziehen, dass die beiden User-Agents grundsätzlich verschiedene Informationen liefern?

Nein, ich ziehe daraus nur den Schluss, dass diese Erweiterung nur die HTTP-Headers und nicht den von Javascript gelieferten Wert oder gar generell den Useragent im Browser ändert. Ganz zu schweigen davon, daraus ein browserübergreifendem Verhalten ableiten zu wollen.

Wäre es dann nicht klüger, immer nur navigator.userAgent abzufragen, da dabei anscheinend stets der "richtige" User-Agent zurückgegeben wird, auch wenn ein manipulierter Header-User-Agent gesendet wird?

Niemand garantiert dir, dass der Useragent nicht auf die eine oder andere Art gefälscht ist. Es wäre klüger, sich gar nicht darauf zu verlassen.

dedlfix.

[lsfr77]

Okay, das heißt also, dass beide Varianten, den User-Agent abzufragen, normalerweise das gleiche Ergebnis liefern.
Vielen Dank für eure interessanten und hilfreichen Beiträge!

LG LSFR77

[Gunther]

Hallo!

Muss ich daraus den Schluss ziehen, dass die beiden User-Agents grundsätzlich verschiedene Informationen liefern?

Die Frage hat dedlfix ja schon beantwortet.

Wäre es dann nicht klüger, immer nur navigator.userAgent abzufragen, da dabei anscheinend stets der "richtige" User-Agent zurückgegeben wird, auch wenn ein manipulierter Header-User-Agent gesendet wird?

Also grundsätzlich würde ich eher davon ausgehen, dass beide Varianten gleich sind. Diese Thematik ist gerade wieder ziemlich aktuell aufgrund der Smartphones. Fast alle Mobile-Versionen der Browser bieten eine Option "Desktop Version anfordern" (oder so ähnlich), die genau so funktioniert. Es wird dabei dann das Wörtchen "mobile" aus dem UA entfernt (in beiden Varianten).

Ich sehe also prinzipiell keinen Unterschied darin, welche Variante man abfragt, da ich grundsätzlich eher davon ausgehen würde, dass beide identisch sind.
Allerdings sehe ich einen großen Unterschied darin, ob man dies server- oder clientseitig macht. Noch dazu wo letztere Variante auch noch aktiviertes JS voraussetzt.

@dedlfix

Niemand garantiert dir, dass der Useragent nicht auf die eine oder andere Art gefälscht ist. Es wäre klüger, sich gar nicht darauf zu verlassen.

Ich halte es für absoluten Schwachsinn und ein längst überholtes Relikt aus Urzeiten, dass man den UA "manipulieren" kann. Überhaupt sind die gesendeten Header Daten IMHO "unzureichend", bzw. enthalten nicht die eigentlich interessanten Informationen.

Aber kurz gesagt: Wer seinen UA manipuliert, weiß entweder genau warum und wozu er dieses tut, oder ansonsten hat er einfach Pech gehabt! Solange einem Web Autor keine anderen Möglichkeiten zur Verfügung stehen, muss man eben mit dem Arbeiten, was da ist!

Gruß Gunther

[Laura Lund]

Aber kurz gesagt: Wer seinen UA manipuliert, weiß entweder genau warum und wozu er dieses tut, oder ansonsten hat er einfach Pech gehabt!

Ich würde ja eher sagen, dass er erst Pech gehabt hat und dann die Kennung manipulieren musste.

Es gibt immer noch genügend Zurückgebliebene unter den Webseitenautoren, die dem Besucher nicht nur ein "Optimiert für Browser sowieso" vorsetzen, sondern aktiv jede sinnvolle Nutzung verhindern, falls der Browser anscheinend keine IE- oder Firefox-Kennung sendet.

Nochmal kurz, aber anders gesagt: Wer den UA abfragt, weiß entweder genau warum und wozu er dieses tut, oder ansonsten ist er einfach zu dusselig.

[Gunther]

Hallo!

Aber kurz gesagt: Wer seinen UA manipuliert, weiß entweder genau warum und wozu er dieses tut, oder ansonsten hat er einfach Pech gehabt!

Ich würde ja eher sagen, dass er erst Pech gehabt hat und dann die Kennung manipulieren musste.

Es gibt immer noch genügend Zurückgebliebene unter den Webseitenautoren, die dem Besucher nicht nur ein "Optimiert für Browser sowieso" vorsetzen, sondern aktiv jede sinnvolle Nutzung verhindern, falls der Browser anscheinend keine IE- oder Firefox-Kennung sendet.

Deiner Argumentation folgend heißt das also, man kann den UA nicht "sinnvoll" verwenden, weil es (leider) Autoren gibt, die ihn "missbräuchlich/ falsch" verwenden!?

Nochmal kurz, aber anders gesagt: Wer den UA abfragt, weiß entweder genau warum und wozu er dieses tut, oder ansonsten ist er einfach zu dusselig.

Ich möchte auf meinen bereits erwähnten Fall zurückkommen, nämlich die Erkennung von Smartphones (Mobile Devices) mit deaktiviertem Javascript.

Und wie bereits ebenfalls kurz erwähnt, fände ich es sehr begrüßenswert, wenn im Header solche Angaben bezüglich des Ausgabemediums übertragen würden, anstatt Autoren qusi zu zwingen, auf "unzuverlässige Behelfskrücken" zurückgreifen zu müssen.

Prinzipiell stehe ich aber auf dem Standpunkt, dass die teilweise "fälschliche" Verwendung von irgendwelchen Dingen kein Grund oder Argument dafür oder dagegen sein kann.

Wenn überhaupt dann kann es lediglich ein als "standardmäßiges" angesehenes Userverhalten sein. Und ich bin mir sehr sicher, dass die breite Masse der User nicht einmal weiß worüber wir hier reden, geschweige denn weiß, wie man den UA manipuliert (oder wozu).

Gruß Gunther

[Laura Lund]

Ich würde ja eher sagen, dass er erst Pech gehabt hat und dann die Kennung manipulieren musste.

Es gibt immer noch genügend Zurückgebliebene unter den Webseitenautoren, die dem Besucher nicht nur ein "Optimiert für Browser sowieso" vorsetzen, sondern aktiv jede sinnvolle Nutzung verhindern, falls der Browser anscheinend keine IE- oder Firefox-Kennung sendet.

Deiner Argumentation folgend heißt das also, man kann den UA nicht "sinnvoll" verwenden, weil es (leider) Autoren gibt, die ihn "missbräuchlich/ falsch" verwenden!?

Diesen Schluss kann man ziehen, ich würde ihn aber nicht aussprechen, weil er vom Grundproblem ablenkt. Es ist meines Erachtens schlicht so, dass da draußen zu viele Browser rumhopsen, als dass ich jeden beim Namen kennen könnte. Wir haben ja nicht nur viereinhalb verschiedene Browserfamilien (IE, Mozilla, Opera, Webkit mit Safari und Chrome, letztere unterscheiden sich im Javascript-Interpreter), die kommen auch noch in hundert verschiedenen Versionen vor.

Ich möchte auf meinen bereits erwähnten Fall zurückkommen, nämlich die Erkennung von Smartphones (Mobile Devices) mit deaktiviertem Javascript.

Und wie bereits ebenfalls kurz erwähnt, fände ich es sehr begrüßenswert, wenn im Header solche Angaben bezüglich des Ausgabemediums übertragen würden, anstatt Autoren qusi zu zwingen, auf "unzuverlässige Behelfskrücken" zurückgreifen zu müssen.

Das kann ich nachvollziehen, aber im Grunde zeigt sich in diesem Punkt etwas, worauf schon vor bald 20 Jahren geachtet wurde: HTML war als vom Ausgabemedium möglichst unabhängiges Format angelegt. Dieser Gedanke ging recht schnell den Bach runter, das fing mit der Erkennung der Bildschirmgröße an, dann der Browserkrieg. Und jetzt kommt's mit den Mobilgeräten ganz dicke - insbesondere für jene, die vor ihrem Gaming-23-Zöller sitzen und gnädig auf "1280x1024 optimieren" ;>

Wie dem auch sei, "unzuverlässig" oder "Behelfskrücken" (oder beides) trifft auf alle Möglichkeiten zu. Ich halte CSS-Mediaqueries für die sicherste Methode, sowohl, was die Funktion angeht als auch die Zukunftssicherheit. Ich erlebe sie zwar selbst als unzuverlässig, aber allemal besser als die Browserweiche, weil schon vom Prinzip her nicht ich entscheiden muss, wie das Ausgabemedium aussieht, sondern sich das Ausgabemedium selbst bewertet und aus meinen Angeboten aussucht.

Prinzipiell stehe ich aber auf dem Standpunkt, dass die teilweise "fälschliche" Verwendung von irgendwelchen Dingen kein Grund oder Argument dafür oder dagegen sein kann.

Da gebe ich dir recht. Jeder ist für den Mist, den er verbockt, selbst verantwortlich. Browserweichen sind aber nichtsdestotrotz so ein Fall, wo man _sehr_ genau wissen sollte, was man tut. Die Anwendungsfälle, in denen mehr Nutzen als Schaden rauskommt, halte ich für überaus selten.

[Gunther]

Hi!

Diesen Schluss kann man ziehen, ich würde ihn aber nicht aussprechen, weil er vom Grundproblem ablenkt. Es ist meines Erachtens schlicht so, dass da draußen zu viele Browser rumhopsen, als dass ich jeden beim Namen kennen könnte. Wir haben ja nicht nur viereinhalb verschiedene Browserfamilien (IE, Mozilla, Opera, Webkit mit Safari und Chrome, letztere unterscheiden sich im Javascript-Interpreter), die kommen auch noch in hundert verschiedenen Versionen vor.

Wie ich in meiner Antwort an Martin schon erwähnt habe, spreche ich ausdrücklich_nicht_von "Browser-Sniffing" per UA, sondern eher von so etwas wie "Device-Sniffing".

Ich möchte auf meinen bereits erwähnten Fall zurückkommen, nämlich die Erkennung von Smartphones (Mobile Devices) mit deaktiviertem Javascript.

Und wie bereits ebenfalls kurz erwähnt, fände ich es sehr begrüßenswert, wenn im Header solche Angaben bezüglich des Ausgabemediums übertragen würden, anstatt Autoren qusi zu zwingen, auf "unzuverlässige Behelfskrücken" zurückgreifen zu müssen.

Das kann ich nachvollziehen, aber im Grunde zeigt sich in diesem Punkt etwas, worauf schon vor bald 20 Jahren geachtet wurde: HTML war als vom Ausgabemedium möglichst unabhängiges Format angelegt. Dieser Gedanke ging recht schnell den Bach runter, das fing mit der Erkennung der Bildschirmgröße an, dann der Browserkrieg. Und jetzt kommt's mit den Mobilgeräten ganz dicke - insbesondere für jene, die vor ihrem Gaming-23-Zöller sitzen und gnädig auf "1280x1024 optimieren" ;>

Das kann ich jetzt nicht so ganz in den Kontext einordnen ...!?
IMHO gibt es seit Jahren (und das Archiv hier kann meine Aussage belegen) das Problem, dass man für das Styling/Design CSS verwendet, es gleichzeitig aber keine "brauchbare" Möglichkeit gibt, etwas über das jeweilige Ausgabemedium zu erfahren. Und genau darauf kommt es aber an.

Um es mal etwas "überspitzt/ übertrieben" auszudrücken:
Bei manchen Websites ist/sind die zugehörige(n) CSS Datei(en) mittlerweile größer, als der eigentliche Inhalt (wenn man mal von Grafiken und Videos absieht).
Oder wenn ich mich und mein Browsingverhalten mal betrachte: Ich surfe täglich 100 verschiedene Seiten an, drucke aber keine einzige davon aus. So gesehen sind die ganzen Print-Styles für mich reiner "Daten Ballast". Denn wenn ich doch mal eine Seite ausdrucken wollte, könnte ich gut damit leben, wenn dann erst das passende Print-Stylesheet nachgeladen würde.

HTML war als vom Ausgabemedium möglichst unabhängiges Format angelegt

HTML ja, aber CSS nicht. Und in Zeiten zunehmender (verschiedener) Ausgabemedien (Stichwort: Mobile Devices), wo es eben teilweise auch neue Dinge gibt, auf die zu achten ist (wie bspw. Datenvolumen), sehe ich das als zunehmendes Problem ...!

Wie dem auch sei, "unzuverlässig" oder "Behelfskrücken" (oder beides) trifft auf alle Möglichkeiten zu. Ich halte CSS-Mediaqueries für die sicherste Methode, sowohl, was die Funktion angeht als auch die Zukunftssicherheit. Ich erlebe sie zwar selbst als unzuverlässig, aber allemal besser als die Browserweiche, weil schon vom Prinzip her nicht ich entscheiden muss, wie das Ausgabemedium aussieht, sondern sich das Ausgabemedium selbst bewertet und aus meinen Angeboten aussucht.

Auch ich beschäftige mich seit geraumer Zeit mit Media Queries (auch hier kann das Archiv dies wieder bestätigen) und ich finde es toll, dass man mittlerweile dank Transitions & Co. Elemente auch ohne JS animieren kann. Umso unverständlicher ist es mir, dass es aktuell keine Möglichkeit gibt so etwas Elementares, wie ob es sich bspw. um ein Ausgabemedium mit Touchscreen handelt, herauszufinden. Einzig Mozilla hat mit '-moz-touch-enabled' so etwas im Repertoir ...!

Und die unterschiedlichen Implementierungen/ Interpretationen seitens der Browserhersteller konterkarieren einen Großteil der Vorteile von MQ, wobei sie aber das eigentliche Problem (s.o.) in keinster Weise lösen.

Prinzipiell stehe ich aber auf dem Standpunkt, dass die teilweise "fälschliche" Verwendung von irgendwelchen Dingen kein Grund oder Argument dafür oder dagegen sein kann.

Da gebe ich dir recht. Jeder ist für den Mist, den er verbockt, selbst verantwortlich. Browserweichen sind aber nichtsdestotrotz so ein Fall, wo man _sehr_ genau wissen sollte, was man tut. Die Anwendungsfälle, in denen mehr Nutzen als Schaden rauskommt, halte ich für überaus selten.

Das sehe ich im Bezug auf "Browserweichen" genauso. Nur wie bereits gesagt, davon sprach und spreche ich nicht. ;-)
Wobei ich ehrlich gesagt auch nicht zwingend einen Nachteil darin sehen würde, wenn es eine verlässliche Methode zur Browserindentifizierung geben würde ...!

Gruß Gunther

[Laura Lund]

Es gibt immer noch genügend Zurückgebliebene unter den Webseitenautoren, die ... aktiv jede sinnvolle Nutzung verhindern, falls der Browser anscheinend keine IE- oder Firefox-Kennung sendet.

Deiner Argumentation folgend heißt das also, man kann den UA nicht "sinnvoll" verwenden, weil es (leider) Autoren gibt, die ihn "missbräuchlich/ falsch" verwenden!?

Diesen Schluss kann man ziehen, ich würde ihn aber nicht aussprechen, weil er vom Grundproblem ablenkt. Es ist meines Erachtens schlicht so, dass da draußen zu viele Browser rumhopsen, als dass ich jeden beim Namen kennen könnte.

spreche ich ausdrücklich_nicht_von "Browser-Sniffing" per UA, sondern eher von so etwas wie "Device-Sniffing".

Wenn du "ausdrücklich nicht" von der Browserkennung sprichst, warum schreibst du dann etwas dazu. Sowas habe ich gerne, von A nach Z springen und Zitate aus dem Zusammenhang reissen :/

Das sehe ich im Bezug auf "Browserweichen" genauso. Nur wie bereits gesagt, davon sprach und spreche ich nicht. ;-)

Vielleicht hast du davon nicht gesprochen, aber du hast davon geschrieben. Und du solltest dir gelegentlich mal durchlesen, was du schreibst, dann würdest du nicht so einen wirren Kram von dir geben.

[Gunther]

Hallo,

nun bleib' doch mal friedlich ... ;-)
Wenn es hier ggf. "Verwirrung" bezüglich der Begrifflichkeiten gibt, dann lassen die sich bestimmt aufklären.

Es gibt immer noch genügend Zurückgebliebene unter den Webseitenautoren, die ... aktiv jede sinnvolle Nutzung verhindern, falls der Browser anscheinend keine IE- oder Firefox-Kennung sendet.

Deiner Argumentation folgend heißt das also, man kann den UA nicht "sinnvoll" verwenden, weil es (leider) Autoren gibt, die ihn "missbräuchlich/ falsch" verwenden!?

Diesen Schluss kann man ziehen, ich würde ihn aber nicht aussprechen, weil er vom Grundproblem ablenkt. Es ist meines Erachtens schlicht so, dass da draußen zu viele Browser rumhopsen, als dass ich jeden beim Namen kennen könnte.

spreche ich ausdrücklich_nicht_von "Browser-Sniffing" per UA, sondern eher von so etwas wie "Device-Sniffing".

Wenn du "ausdrücklich nicht" von der Browserkennung sprichst, warum schreibst du dann etwas dazu. Sowas habe ich gerne, von A nach Z springen und Zitate aus dem Zusammenhang reissen :/

Also wir reden von derselben Angabe, nämlich dem User Agent (UA) im Header. Wo du mich nur scheinbar missverstanden hast, ist die "Motivation" bzw. der Grund, warum/wofür man die Angabe nutzt.
Unter "Browser-Sniffing" verstehe ich, dass die Angabe (sofern vorhanden) dahingehend genutzt/ausgewertet wird, um was für einen Browser (also bspw. IE, FF, Opera, Chrome etc.) es sich handelt.
Unter "Device-Sniffing" verstehe ich, dass die Angabe (sofern vorhanden) dahingehend genutzt/ausgewertet wird, um was für eine Art Ausgabegerät es sich handelt, bzw. ob es sich um ein mobiles Endgerät handelt.

Das sehe ich im Bezug auf "Browserweichen" genauso. Nur wie bereits gesagt, davon sprach und spreche ich nicht. ;-)

Vielleicht hast du davon nicht gesprochen, aber du hast davon geschrieben. Und du solltest dir gelegentlich mal durchlesen, was du schreibst, dann würdest du nicht so einen wirren Kram von dir geben.

BTW: Ich lese mir immer erst die Vorschau nochmal durch, bevor ich einen Beitrag poste. ;-)
"Browserweichen", d.h. also "Browser-Sniffing" (gem. obiger Definition) sollte man imho nicht betreiben. Mir fällt dafür zumindest kein triftiger Grund ein. Anders beim "Device-Sniffing", weil es da eben momentan keine andere Alternative gibt. Das gilt nur für den Fall, dass kein Javascript verfügabr/ aktiviert ist!

Und wie bereits erwähnt "drängen" die Browserhersteller ja geradezu in diese Richtung, dadurch dass sie in ihre mobilen Browserversionen genau diesen Switch (zw. Mobile- + Desktopversion) per UA einbauen.

Somit steht man als Autor quasi schon wieder vor dem nächsten Dilemma ...!
Wertet man den UA nicht aus, schaltet man damit quasi die im Browser integrierte Funktion aus, von der der User aber ggf. erwartet, dass sie funktioniert.

Gruß Gunther

[Der Martin]

Hi,

Es gibt immer noch genügend Zurückgebliebene unter den Webseitenautoren, die dem Besucher nicht nur ein "Optimiert für Browser sowieso" vorsetzen, sondern aktiv jede sinnvolle Nutzung verhindern, falls der Browser anscheinend keine IE- oder Firefox-Kennung sendet.
Deiner Argumentation folgend heißt das also, man kann den UA nicht "sinnvoll" verwenden, weil es (leider) Autoren gibt, die ihn "missbräuchlich/ falsch" verwenden!?

so ähnlich - besser: Weil es Autoren gibt, die dem User-Agent-Header eine Bedeutung beimessen, die er nicht hat. Denn nirgends ist festgelegt, was im User Agent zu stehen hat und was nicht. Das kann jeder HTTP-Client nach Gutdünken festlegen, oder gar die Einstellung dem Nutzer überlassen.

Und wie bereits ebenfalls kurz erwähnt, fände ich es sehr begrüßenswert, wenn im Header solche Angaben bezüglich des Ausgabemediums übertragen würden, anstatt Autoren qusi zu zwingen, auf "unzuverlässige Behelfskrücken" zurückgreifen zu müssen.

Das wäre sicher schön, aber es ist nun mal nicht so.

Prinzipiell stehe ich aber auf dem Standpunkt, dass die teilweise "fälschliche" Verwendung von irgendwelchen Dingen kein Grund oder Argument dafür oder dagegen sein kann.

Prinzipiell stehe ich auf dem Standpunkt, dass man sich nicht auf Informationen verlassen darf, bei denen weder ihr Inhalt, noch ihr Vorhandensein vorgeschrieben ist. Wusstest du, dass der UA-Header von der HTTP-Spec nicht einmal gefordert ist?

Und ich bin mir sehr sicher, dass die breite Masse der User nicht einmal weiß worüber wir hier reden, geschweige denn weiß, wie man den UA manipuliert (oder wozu).

Das ist sicher richtig. Aber es sind ja nicht nur die Nutzer von Browsern, die bewusst den User Agent "verstellen". Es sind die Browserhersteller selbst, die ihren Browser als einen anderen ausgeben (wie z.B. Opera 6 bis 8, der sich in der Defaulteinstellung als Internet Explorer ausgab); es sind manche Virenscanner, Software-Firewalls und Proxies, die den UA gezielt manipulieren; es sind auch Hersteller wie Microsoft, die im UA ihres Browsers auch noch Detailinformationen des Betriebssystems unterbringen (z.B. über ein eventuell installiertes .NET-Framework).

Und so verkommt der UA zum Schmierzettel, der kaum noch sinnvoll zu gebrauchen ist.

Ciao,
 Martin

[Gunther]

Hi Martin!

Es gibt immer noch genügend Zurückgebliebene unter den Webseitenautoren, die dem Besucher nicht nur ein "Optimiert für Browser sowieso" vorsetzen, sondern aktiv jede sinnvolle Nutzung verhindern, falls der Browser anscheinend keine IE- oder Firefox-Kennung sendet.
Deiner Argumentation folgend heißt das also, man kann den UA nicht "sinnvoll" verwenden, weil es (leider) Autoren gibt, die ihn "missbräuchlich/ falsch" verwenden!?

so ähnlich - besser: Weil es Autoren gibt, die dem User-Agent-Header eine Bedeutung beimessen, die er nicht hat. Denn nirgends ist festgelegt, was im User Agent zu stehen hat und was nicht. Das kann jeder HTTP-Client nach Gutdünken festlegen, oder gar die Einstellung dem Nutzer überlassen.

Korrekt. Nur um das vlt. nochmal klar zu stellen: Ich bin kein grundsätzlicher Befürworter der Verwendung des UA für was auch immer, und ich halte ihn bestenfalls eben für eine "Behelfskrücke". Ich mag nur keine Aussagen, die pauschal die Verwendung des UAs "verteufeln" - zumindest aktuell nicht, wo es eben teilweise keine anderen Möglichkeiten gibt.

Und wie bereits ebenfalls kurz erwähnt, fände ich es sehr begrüßenswert, wenn im Header solche Angaben bezüglich des Ausgabemediums übertragen würden, anstatt Autoren qusi zu zwingen, auf "unzuverlässige Behelfskrücken" zurückgreifen zu müssen.

Das wäre sicher schön, aber es ist nun mal nicht so.

Ja und!? ;-)
Wenn wir nicht ab und zu mal "laut poltern/ meckern", dann wird sich das vermutlich auch in Zukunft nicht ändern.

Prinzipiell stehe ich aber auf dem Standpunkt, dass die teilweise "fälschliche" Verwendung von irgendwelchen Dingen kein Grund oder Argument dafür oder dagegen sein kann.

Prinzipiell stehe ich auf dem Standpunkt, dass man sich nicht auf Informationen verlassen darf, bei denen weder ihr Inhalt, noch ihr Vorhandensein vorgeschrieben ist. Wusstest du, dass der UA-Header von der HTTP-Spec nicht einmal gefordert ist?

Ja, wusste ich. ;-)
Und trotzdem gehen gerade die Browserhersteller hin, und verwenden eben genau diesen, um zwischen einer Mobile- und Desktopversion zu differenzieren. Als Autor ist man ja letztlich immer an das gebunden, was verfügbar ist (ob "offizieller" Standard oder nicht - das ist eh ein Kapitel für sich).

Und ich bin mir sehr sicher, dass die breite Masse der User nicht einmal weiß worüber wir hier reden, geschweige denn weiß, wie man den UA manipuliert (oder wozu).

Das ist sicher richtig. Aber es sind ja nicht nur die Nutzer von Browsern, die bewusst den User Agent "verstellen". Es sind die Browserhersteller selbst, die ihren Browser als einen anderen ausgeben (wie z.B. Opera 6 bis 8, der sich in der Defaulteinstellung als Internet Explorer ausgab); es sind manche Virenscanner, Software-Firewalls und Proxies, die den UA gezielt manipulieren; es sind auch Hersteller wie Microsoft, die im UA ihres Browsers auch noch Detailinformationen des Betriebssystems unterbringen (z.B. über ein eventuell installiertes .NET-Framework).

Alles richtig.
Aber ich spreche hier ausdrücklich von den Fällen, wo es um "Device-Sniffing" (nicht Browser-Sniffing) bei deaktiviertem Javascript geht!

Und so verkommt der UA zum Schmierzettel, der kaum noch sinnvoll zu gebrauchen ist.

Ja, leider.
Höchste Zeit, dass in diesem Bereich mal Abhilfe geschaffen wird (nicht zwingend per UA)!
Denn in Zeiten, wo es u.a. um Bandbreiteneinsparung u.ä. geht, ist es IMHO ein Unding, dass es serverseitig (und nur da liegt der wirkliche Vorteil) keine brauchbare und verlässliche Möglichkeit gibt, etwas über das Ausgabemedium zu erfahren.

Ciao,
Martin

Gruß Gunther