Herzlich willkommen im Archiv vom ABAKUS Online Marketing Forum
Du befindest Dich im Archiv vom ABAKUS Online Marketing Forum. Hier kannst Du Dich für das Forum mit den aktuellen Beiträgen registrieren.
Code: Alles auswählen
AddDefaultCharset utf-8
Besorge dir Firefox und dazu Firebug oder LiveHTTPHeaders. Beide Erweiterungen erlauben es, die HTTP-Protokolldaten anzuzeigen, die zwischen Browser und Server ausgetauscht werden (LiveHTTPHeaders: über den Seiteninformationen-Dialog; Firebug: auf der Net-Seite), so dass du selbst prüfen kannst, ob dein Server die utf-8-Angabe sendet. Vermutlich ist das nicht der Fall, funktioniert denn die .htaccess überhaupt?RolWg hat geschrieben:wenn ich mittels .htaccess das character encoding vorgebe,beschwert sich der W3C-Validator, er fände keines.Code: Alles auswählen
AddDefaultCharset utf-8
Als Antwort Header bekomme ich:Mork vom Ork hat geschrieben: Besorge dir Firefox und dazu Firebug oder LiveHTTPHeaders. ...
Vermutlich ist das nicht der Fall, funktioniert denn die .htaccess überhaupt?
Code: Alles auswählen
RESPONSE HTTP/1.1 200 OK
Date Sun, 24 May 2009 13:50:45 GMT
Server HTTPD
X-Powered-By PHP/5.2.5
Expires Fri, 22 May 2009 19:15:43 GMT
Last-Modified Fri, 22 May 2009 19:15:43 GMT
Keep-Alive timeout =5, max = 100
Connection Keep-Alive
Transfer-Encoding chunked
Content-Type text/html; charset=utf-8
Content-Language de
imagetoolbar false
content-srcipt-type text/javascript
Code: Alles auswählen
No Character Encoding Found! Falling back to UTF-8.
Code: Alles auswählen
No Character Encoding Found! Falling back to ISO-8859-1.
Code: Alles auswählen
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
Wenn du in dieser Seite kein <meta>-Content-Type-Element hast, dann gibt der Server die Zeichenkodierung korrekt aus, AddDefaultCharset funktioniert also und die Validator-Meldung muss eine andere Ursache haben.RolWg hat geschrieben:Als Antwort-Header bekomme ich:Code: Alles auswählen
RESPONSE HTTP/1.1 200 OK [..] Content-Type: text/html; charset=utf-8
Das ist vollkommen normal. Wenn du von Oma am Telefon das Kirschkuchenrezept haben möchtest und dann gleich noch wissen willst, ob sie Sonntag zum Kaffee kommt, wählst du ja auch nicht zweimal, sondern stellst beide Fragen in derselben Verbindung. Genauso läuft es zwischen Browser und Server, der Browser stellt nicht für jede Grafik und was sonst noch von einer Seite benötigt wird, eine neue Verbindung her, sondern benutzt die, die er schon hat. Erhöht die Geschwindigkeit und verringert die Netzlast.Merkwürdig finde ich "Connection Keep-Alive" und "Transfer-Encoding chunked"
Wenn der Benutzer deine Seite auf seinem Rechner abspeichert (nicht als Lesezeichen, sondern richtig als Datei), dann geht zumindest bei Firefox die per HTTP übermittelte Information zur Zeichenkodierung verloren. Da der Standardzeichensatz iso-8859-1 bzw. windows-1252 ist, gibt's Zeichensalat, ist die Seite eigentlich utf-8-kodiert. Schreibst du die Zeichenkodierung stattdessen als <meta>-Element in Seite, stellt sich das Problem logischerweise nicht.Gibt's da eigentlich Regeln, welches von beiden wann besser genommen werden sollte?
Also ich liefere die Kodierung wie du im HTTP-Kopf, nicht als <meta>, und bekomme "This document was successfully checked as HTML 4.01 Strict!", trotz des Hinweises "No Character encoding declared at document level".Genaugenommen schreibt der W3C-Validator:
"This document was Tentatively checked as XHTML 1.0 Transitional"
Diese "Vorläufigkeit" bezieht sich auf das ausschließliche Encoding mittels .htaccess.
Es gibt verschiedene Möglichkeiten, in der Serverkonfiguration festzulegen, ob und welche Kodierungsinformation per HTTP ausgegeben wird. Mit AddDefaultCharset legst du fest, dass alle (Text-) Objekte, die nicht von sonstwoher eine Kodierungsinfo haben, eine Standardkodierungsinfo verpasst bekommen.dann ist das Encoding mittels .htaccess nur ein "default-overriding"?
meinte ich aber mit "beiden"RolWg hat geschrieben: Gibt's da eigentlich Regeln, welches von beiden wann besser genommen werden sollte?
Nachvollziehbar, da der W3C-Validator dann wohl die Angabe aus dem <meta>-Teil nimmt und sich damit zufrieden gibt.RolWg hat geschrieben:Wenn ich sowohl die .htaccess benutze als auch http-equiv, dann meckert W3C nicht mehr
Ich denke, da zieht dich ein vermutliches Fehlverhalten (Nicht-Erkennen der Angabe im HTTP-Kopf) zu einem falschen Schluss.sowohl die .htaccess benutze als auch http-equiv […] ist aber wohl im Sinne von validem Code der ausschließlichen Angabe in der .htaccess (mit den beschriebenen Nebenwirkungen "tentatively") vorzuziehen.
geht aber auch.
?
Sprich, mache mal aus DeinemThe old URL-path is a case-sensitive (%-decoded) path beginning with a slash. A relative path is not allowed. The new URL should be an absolute URL beginning with a scheme and hostname.
Redirect /service https://foo2.bar.com/service
Ob das so strukturiert ist, wie du gerne möchtest, weiß ich nicht, aber ich gucke seit jeher einfach in die Originalanleitung: https://httpsd.apache.org/docs/2.2/, unter https://httpsd.apache.org/docs/2.2/mod/ ... rence.html findest du sämtliche Anweisungen, unter https://httpsd.apache.org/docs/2.2/mod/ eine Übersicht über die einzelnen Module.RolWg hat geschrieben:Kannst Du vielleicht 'nen Tipp verteilen, wo ich das strukturiert nachlesen kann?
LiveHTTPHeaders ist sehr praktisch. Zusätzlich solltest du [url=https://getfirebug[/url]Firebug[/url] installieren.wie am besten testen (Live http-headers)?
Steht oben.Eigentlich wollte ich "nur" eindeutig und ein für allemal UTF-8 festlegen,
Wenn's die Startseite ist, was macht sie dann in einem Unterverzeichnis? Das hört sich für mich so an, als wenn du deinem Auto einen Esel vorspannen möchtest, anstatt den Motor zu reparieren.meine Startseite in einem Unterverzeichnis (statt index.php im root)
userfreundliche Fehlerseiten für 404er und 500er-Fehler machen./quote]
ErrroDocument
Die .htaccess ist für Hosting-Kunden in der Regel der einzigste Weg, Apache-Einstellungen unterzubringen, insofern geht es nicht ohne. Ich empfehle nur, die .htaccess nicht zu groß werden zu lassen, weil sie bei jeder Anfrage mindestens einmal eingelesen wird. 300 einzelne Weiterleitungen vom Wurzelverzeichnis aus täte ich zum Beispiel lieber in ein Skript auslagern, 300 einzelne Weiterleitungen in einem bestimmten Ordner in eine .htaccess in diesem Ordner (statt in /.htaccess).Da fand ich den Schritt ganz systematisch, das alles per .htaccess zu regeln.
(Irgendwo in diesem Forum empfiehlst glaube ich Du, genau das nicht zu machen, um die vielen .htaccess-Zugriffe zu minimieren?)
Auch nicht richtig, Location benötigt eine vollständige URL.und nur _alternativ_ der php-Befehl in der index.php :
"header ("Location: kategorie1/thema1.php");" in der index.php bei meinem Provider ausgeführt.
Code: Alles auswählen
header ("Location: frontend/01_home/home.php");
Ich meinte tatsächlich nicht nur die redirects sondern auch 'ne Argumentation,Mork vom Ork hat geschrieben:RolWg hat geschrieben:Kannst Du vielleicht 'nen Tipp verteilen, wo ich das strukturiert nachlesen kann?
Code: Alles auswählen
AddDefaultCharset utf-8
redirect 301 /index.php http://TLD.de/frontend/01_home/home.php
Code: Alles auswählen
<meta http-equiv="content-language" content="de" />
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta http-equiv="imagetoolbar" content="false" />
Code: Alles auswählen
header ("Location: frontend/01_home/home.php");
Code: Alles auswählen
<meta name="language" content="de" />
Praktisch nicht, theoretisch schon. Und da wir ja alle schön nach Standard arbeiten und selbiger unmissverständlich sagt: „absoluteURI“ … Vielleicht kann ich dich ja mit header("Location: http://" . $_SERVER["HTTP_HOST"] . "/frontend/01_home/home.php"); vom Pfad des Lichts überzeugen ;)RolWg hat geschrieben:Und der relative Pfadfunktioniert prima. Da muß kein http://... vor.Code: Alles auswählen
header ("Location: frontend/01_home/home.php");
Das ist einfach: <meta>-http-equiv ist, wie der Name schon andeutet, im Endeffekt das Gleiche wie header() - header() gibt Daten in den HTTP-Strom aus, http-equiv steht für Daten, die zum HTTP-Strom gehören sollen. Der Vorteil von header() ist, dass eventuell nicht jedes Programm <meta>-http-equiv verarbeitet, der Vorteil von <meta>-http-equiv ist wiederum, dass die Informationen auch dann nicht verloren gehen, wenn der Besucher die Seite auf seinem Rechner abgespeichert.Ich meinte tatsächlich nicht nur die redirects sondern auch 'ne Argumentation, wann .htaccess, wann lieber http-equiv, wann lieber header
betrifft, halte ich mich an die Grundregel, für alles, für was es einen relevanten Standard gibt (RFC ist relevant, „benutzen alle“ nicht), keinen anderen Kram zu benutzen. Content-Language ist im HTTP-Protokoll definiert, da braucht's kein zusätzliches <meta>-language.<meta name="language" content="de" />
Theoretisch ja ...Mork vom Ork hat geschrieben: … Vielleicht kann ich dich ja mit header("Location: http://" . $_SERVER["HTTP_HOST"] . "/frontend/01_home/home.php"); vom Pfad des Lichts überzeugen
Nee, ja, das kommt auf den Anwendungsfall an. Grundsätzlich .htaccess, nimmt die jedoch monströse Ausmaße an, sollte man sich überlegen, ob's nicht eine schlankere Möglichkeit gibt. Wann aber nun was praktikabel ist, hängt -wie gesagt- vom Einzelfall ab - da hilft nur der gesunde Menschenverstand.RolWg hat geschrieben:Aber das ist ja wieder PHP und nicht .htaccess
und ich dachte, Umleitungen / redirects, etc. stringent nur in dieser ?
Mork vom Ork hat geschrieben: Nee, ja, das kommt auf den Anwendungsfall an. Grundsätzlich .htaccess, nimmt die jedoch monströse Ausmaße an, sollte man sich überlegen, ob's nicht eine schlankere Möglichkeit gibt. Wann aber nun was praktikabel ist, hängt -wie gesagt- vom Einzelfall ab - da hilft nur der gesunde Menschenverstand.
Den jeder glaubt, zu haben ...,
404er, 500er-FehlerseitenMork vom Ork hat geschrieben: Auf deine header()/Location:-Verwendung bin ich nur eingegangen, weil du sie genannt hattest.
Ich weiß nicht, was du da oben mit „etc“ meintest