nicht angemeldet
403 statt 404
Hallo,
ich habe jetzt eigene Fehlerseiten für die Statuscodes 401, 403 und 404 geschrieben und in die .htaccess eingetragen. Beim Testen mußte ich dann feststellen, dass ich immer einen 403 erhalte, auch wenn ich eine Seite angebe die nicht existiert (eigentlich ja 404) z.B. www.domainname.de/existiertnicht.html .
Die Fehlerseiten sind richtig zugeordnet. Woran kann so etwas liegen?
Gruß,
Henning
-
ich habe jetzt eigene Fehlerseiten für die Statuscodes 401, 403 und 404 geschrieben und in die .htaccess eingetragen. Beim Testen mußte ich dann feststellen, dass ich immer einen 403 erhalte, auch wenn ich eine Seite angebe die nicht existiert (eigentlich ja 404) z.B. www.domainname.de/existiertnicht.html .
Die Fehlerseiten sind richtig zugeordnet. Woran kann so etwas liegen?Kannst Du die Fehlerseiten direkt ansteuern (z.B. server.de/error/404.html)? Erhälst Du die richtige Fehlermeldung, wenn Du ErrorDocument ganz raus nimmst? Hast Du geprüft, ob der Fehler einen Code X liefert oder hast Du nur gesehen, daß die Fehlerseite für Code X kommt? Und am allerwichtigsten: Was steht in der error_log?
Gruß,
soenk.e-
Kannst Du die Fehlerseiten direkt ansteuern (z.B. server.de/error/404.html)?
Ja
Erhälst Du die richtige Fehlermeldung, wenn Du ErrorDocument ganz raus nimmst?
Nein, ich erhalte auch einen 403 statt 404Hast Du geprüft, ob der Fehler einen Code X liefert oder hast Du nur gesehen, daß die Fehlerseite für Code X kommt? Und am allerwichtigsten: Was steht in der error_log?
Ich habe ein access_log in dem die Codes für die angeforderten Seiten drin stehen und dort steht auch immer ein 403.
z.B ich habe keine index.html sondern index.php. Jemand wollte die index.html aufrufen und bekam einen 403.Gruß,
Henning-
Kannst Du die Fehlerseiten direkt ansteuern (z.B. server.de/error/404.html)?
JaErhälst Du die richtige Fehlermeldung, wenn Du ErrorDocument ganz raus nimmst?
Nein, ich erhalte auch einen 403 statt 404Putzig, kontaktiere besser Deinen Hoster, da scheint schon in der Hauptkonfiguration irgendetwas extrem schief zu laufen.
Gruß,
soenk.ePS: Kann man sich dieses Phänomen mal anschauen?
-
PS: Kann man sich dieses Phänomen mal anschauen?
Natürlich.
Ich habe dafür die Standardfehlerseiten wieder eingestellt.
403:http://www.feuerwehr-timmerlah.de/index.html
Normale Startseite ist die index.php
Werde wohl mal beim Hoster nachfragen.Gruß,
Henning-
PS: Kann man sich dieses Phänomen mal anschauen?
Natürlich.
Ich habe dafür die Standardfehlerseiten wieder eingestellt.
Normale Startseite ist die index.php
Werde wohl mal beim Hoster nachfragen.Gruß,
Henninghi henning,
mal was anderes: hast du dir die seite schon mal im opera angeschaut? da scrollt alles (ausser das menü) mit. d.h. die obere leiste mit den bildern im hintergrund. und alles aus dem content scrollt da auch drüber. schaut sehr merkwürdig aus und war sicher nicht gewollt, oder?
mandy
-
Der Provider hat sich gemeldet: Für das Homeverzeichnis war nicht chmod 755 gesetzt. Jetzt kriege ich auch 404 Fehler.
Wegen Opera: Der obere Bannerbereich ist position:fixed im Mozilla ist es korrekt, im IE scrollt alles (da er position:fixed nicht versteht).
Opera habe ich nicht, aber ich dachte der versteht auch position:fixed?Gruß,
Henning-
Hi Henning,
Wegen Opera: Der obere Bannerbereich ist position:fixed im Mozilla ist es korrekt, im IE scrollt alles (da er position:fixed nicht versteht). Opera habe ich nicht, aber ich dachte der versteht auch position:fixed?
das ist richtig, allerdings ist das Hintergrundbild nicht fixiert und scrollt daher weg. Füge in div#banner noch background-attachment:fixed; ein. Allerdings hat Opera 6 hier tatsächlich ein Problem, weil die Focusbox trotzdem wegscrollt. Das sollte dich aber nicht weiter stören.
Weiters wäre es vorteilhaft, noch den z-index der einzelnen DIVs anzugeben, damit der Inhalt unter dem Banner-DIV wegscrollt.
Noch ein Tip: Da du ohnehin alles per CSS formatierst, wofür du dickes Lob verdienst ;) setze vielleicht die Navigation im Quelltext an das Ende der Seite. Wenn man mit einem Textbrowser oder gar Screenreader auf die Seite kommt, liest man auf jeder Seite immer alle Links, bevor man zum Inhalt kommt. Das ist IMHO auf die Dauer ziemlich lästig. Du kannst ja am Beginn der Seite einen Ankerverweis auf die Navi-ID setzen und per CSS verstecken.
Wichtig: http://www.opera.com/download/ 3,4 MB wirst du dir wenigstens zum Testen leisten können ;)
LG Orlando
-
Hallo, Orlando,
Noch ein Tip: Da du ohnehin alles per CSS formatierst, wofür du dickes Lob verdienst ;) setze vielleicht die Navigation im Quelltext an das Ende der Seite. Wenn man mit einem Textbrowser oder gar Screenreader auf die Seite kommt, liest man auf jeder Seite immer alle Links, bevor man zum Inhalt kommt. Das ist IMHO auf die Dauer ziemlich lästig. Du kannst ja am Beginn der Seite einen Ankerverweis auf die Navi-ID setzen und per CSS verstecken.
Es ist mehr oder weniger egal, denn so oder so wäre es klug, an den Anfang einen Link zur Navigation zu setzen, wenn man sie am Ende des Dokuments positioniert, oder einen Link zum Überspringen der Navigation anzubieten, wenn man sie am Anfang positioniert. Der tabindex müsste auch immer so gesetzt sein, dass die Navigation zuerst kommt.
Es gibt viele Szenarien, auf welche hin man die Benutzbarkeit einer Seite verbessern kann. Gegen die Navigation am Ende der Seite könnte man argumentieren, dass es leichter ist, die angelesene Seite über eine Navigation am Anfang zu verlassen als dass man sich bis zum Dokumentende durcharbeiten muss. Indem man einen Abstract an den Dokumentanfang in der Nähe der Navigation legt, kann man bewirken, dass der Benutzer sofort weiß, was ihn erwartet.
Man kann sich also über die Vor- und Nachteile der beiden Versionen streiten. Ich vertrete die Meinung, dass eine Navigation am Anfang einer Seite viel hilfreicher ist, da würde ich nicht in erster Linie nur an Screenreaderbenutzer denken. Für sehende Benutzer ist eine Navigation am Seitenanfang m.M.n. viel intuitiver zu bedienen, sie ist auch auf jeder Seite sofort im Blickfeld und bleibt immer an derselben Stelle; zu einer Navigation am Seitenende hingegen muss immer gescrollt werden oder durch einen Link gesprungen werden. (Für den Fall, dass CSS ausgeschaltet ist, ansonsten erscheint die Navigation sowieso am Dokumentanfang.)
(Wo würde man denn ein Inhaltsverzeichnis unterbringen - auch am Ende der Seite? ;))AFAIK sind die Möglichkeiten, von einer Überschrift zur nächsten zu springen, nicht bei allen Zusatztools vorhanden, deshalb sind Links immer hilfreich. Abgesehen davon weiß ich auch nicht, ob Screenreader im Linkmodus (Links werden zuerst vorgelesen) den tabindex berücksichtigen, es könnte also sein, dass die Navigation zuletzt vorgelesen wird, was oft gar nicht hilfreich ist, bspw. wenn man auf eine Seite kommt und sich orientieren muss, was natürlich durch Querverweise jederzeit möglich ist. Ein Link "Zur Navigation" würde AFAIK in diesem Vorlesemodus keinen direkten Nutzen haben.
Und jetzt ärgere ich mich zum wiederholten Male dass die w3c-wai-de-Mailingliste kein Archiv hat.Grüße,
Mathias-
Hi Mathias,
Es ist mehr oder weniger egal, denn so oder so wäre es klug, an den Anfang einen Link zur Navigation zu setzen, wenn man sie am Ende des Dokuments positioniert, oder einen Link zum Überspringen der Navigation anzubieten, wenn man sie am Anfang positioniert. Der tabindex müsste auch immer so gesetzt sein, dass die Navigation zuerst kommt.
ACK
Es gibt viele Szenarien, auf welche hin man die Benutzbarkeit einer Seite verbessern kann. Gegen die Navigation am Ende der Seite könnte man argumentieren, dass es leichter ist, die angelesene Seite über eine Navigation am Anfang zu verlassen als dass man sich bis zum Dokumentende durcharbeiten muss. Indem man einen Abstract an den Dokumentanfang in der Nähe der Navigation legt, kann man bewirken, dass der Benutzer sofort weiß, was ihn erwartet.
Tja, darüber lässt sich trefflich streiten. Ich finde es nämlich lästig, wenn mir auf jeder Seite sofort die Navigation vor den Latz geknallt wird - ich will sie ja nicht auswendig lernen ;) Nachdem ich den Inhalt gelesen habe, entscheide ich mich ja erst, wo's denn nun weitergehen soll.
Ich vertrete die Meinung, dass eine Navigation am Anfang einer Seite viel hilfreicher ist, da würde ich nicht in erster Linie nur an Screenreaderbenutzer denken. Für sehende Benutzer ist eine Navigation am Seitenanfang m.M.n. viel intuitiver zu bedienen, sie ist auch auf jeder Seite sofort im Blickfeld und bleibt immer an derselben Stelle;
Wenn sie am Ende ist, ist sie auch immer an der selben Stelle und nach der ersten Seite weiß man, wo sie ist.
zu einer Navigation am Seitenende hingegen muss immer gescrollt werden oder durch einen Link gesprungen werden. (Für den Fall, dass CSS ausgeschaltet ist, ansonsten erscheint die Navigation sowieso am Dokumentanfang.)
Klar, der Link darf nicht fehlen - ist er vorhanden, sehe ich das Problem nicht (...ein *g*).
(Wo würde man denn ein Inhaltsverzeichnis unterbringen - auch am Ende der Seite? ;))
Nein, natürlich in einer Sitemap ;)
AFAIK sind die Möglichkeiten, von einer Überschrift zur nächsten zu springen, nicht bei allen Zusatztools vorhanden, deshalb sind Links immer hilfreich.
Genau da liegt das Problem, ich kenne keine diesbezüglichen Zusatztools und alles, was ich ergoogelt habe, ist kostenpflichtig.
Abgesehen davon weiß ich auch nicht, ob Screenreader im Linkmodus (Links werden zuerst vorgelesen) den tabindex berücksichtigen, es könnte also sein, dass die Navigation zuletzt vorgelesen wird, was oft gar nicht hilfreich ist, bspw. wenn man auf eine Seite kommt und sich orientieren muss, was natürlich durch Querverweise jederzeit möglich ist. Ein Link "Zur Navigation" würde AFAIK in diesem Vorlesemodus keinen direkten Nutzen haben.
Speziell zu diesem Punkt konnte ich bisher keine Informationen finden, leider.
LG Orlando
-
Hallo, Orlando.
Es gibt viele Szenarien, auf welche hin man die Benutzbarkeit einer Seite verbessern kann. Gegen die Navigation am Ende der Seite könnte man argumentieren, dass es leichter ist, die angelesene Seite über eine Navigation am Anfang zu verlassen als dass man sich bis zum Dokumentende durcharbeiten muss. Indem man einen Abstract an den Dokumentanfang in der Nähe der Navigation legt, kann man bewirken, dass der Benutzer sofort weiß, was ihn erwartet.
Tja, darüber lässt sich trefflich streiten. Ich finde es nämlich lästig, wenn mir auf jeder Seite sofort die Navigation vor den Latz geknallt wird - ich will sie ja nicht auswendig lernen ;) Nachdem ich den Inhalt gelesen habe, entscheide ich mich ja erst, wo's denn nun weitergehen soll.
Wie gesagt, vielleicht willst du den Inhalt gar nicht komplett lesen und hörst schon nach dem Abstract auf. So ist es m.E. eher, auch "Scannen" genannt, dürfte bekannt sein, die schnelle Suche nach Informationen. Wenn dem Benutzer nicht augenblicklich weitere Seiten angeboten werden (d.h. ohne dass er zu ihnen scollen oder springen muss), wird er die Seite schnell verlassen.
Ich finde kein Artikel, der es belegt, dass man eine Navigationsleiste unbedingt oben anbringen sollte... nur Artikel, die generell Navigationen zugunsten breadcrumb trails verleugnen, das kann ich aber nicht nachvollziehen. Ich bin weiter der Meinung, dass eine Navigation am Anfang einer Seite stehen sollte, da sie sofort im Blickfeld ist.
In dciwam gibt es dutzende Diskussionen darüber, aber dass eine Navigation konventionell vorne im Dokument steht, wird nicht hinterfragt (das soll kein Argument sein ;)).Ich vertrete die Meinung, dass eine Navigation am Anfang einer Seite viel hilfreicher ist, da würde ich nicht in erster Linie nur an Screenreaderbenutzer denken. Für sehende Benutzer ist eine Navigation am Seitenanfang m.M.n. viel intuitiver zu bedienen, sie ist auch auf jeder Seite sofort im Blickfeld und bleibt immer an derselben Stelle;
Wenn sie am Ende ist, ist sie auch immer an der selben Stelle und nach der ersten Seite weiß man, wo sie ist.
Naja, dieses Suchen bzw. anwählen des oben angebrauchten Links möchte ich meinen Benutzern nicht zumuten. Als Benutzer habe ich es immer lieber, wenn eine Navigation am Anfang der Seite steht, zumindest ein breadcrumb trail. Ich will *sofort* wissen, *wo* ich mich auf einer Seite befinde und wie diese Seite im Kontext zu anderen Seiten des Angebots steht. Das dass auf den ersten Block erkennbar wird, finde ich unabdingbar. Wenn ich das alles ans Ende der Seite stelle, bin ich mir nicht einmal sicher, ob der Benutzer je dahin vordringt bzw. vordringen will.
Worüber streiten wir uns eigentlich? Nicht darüber, wo man die Navigation positioniert, sondern darüber, ob sie im Quelltext vorne oder hinten steht, was nur für die Non-CSS-Benutzer relevant ist. Wieso ist es gerade für die sinnvoll, die Navigation am Ende zu positionieren, wenn wir uns einig sind, dass die Navigation per CSS sowieso "am Anfang" der Seite ( || neben dem Inhalt) angebracht wird? Ich sehe kein Unterschied, deshalb lege ich für beide Gruppen denselben Maßstab an.(Wo würde man denn ein Inhaltsverzeichnis unterbringen - auch am Ende der Seite? ;))
Nein, natürlich in einer Sitemap ;)
Ich meinte ein dokumentinternes Inhaltsverzeichnis. Für eine dokumentübergreifende Navigation verwende ich immer "Navigation", für ein dokumentübergreifendes Inhaltsverzeichnis "Sitemap".
Siehe auch http://groups.google.at/groups?selm=amqcbs%2482t0b%243%40ID-143025.news.dfncis.de ff.Hier mal eine Mail aus W3C-WAI-DE bzgl. navigationüberspingenden Links. (Kontext: jemand behauptete, diese Links seien unangebracht, daraufhin meine Nachricht. Ich habe gerade auf Sylpheed Claws gewechselt und habe die alten Nachrichten nicht gespeichert.) Ich zitiere es einfach mal eigenmächtig.
---
Date: Mon, 21 Oct 2002 18:47:06 +0200
From: "Michael Berger" bmf70@gmx.net
To: w3c-wai-de@bi.fraunhofer.de
Subject: Re: [W3C-WAI-DE] Textversionen (was: Neu hier und einige
Fragen)Hallo Mathias!
Du schriebst bereits am Samstag:Kann mir das jemand einmal bitte erklären? - Laut WCAG werden sowohl
Links zum Überspringen großer Linkgruppen als auch Trennzeichen
zwischen Links vorgeschlagen, und beides leuchtet mir ein. Wenn ich
mich recht entsinne, wurde letzteres erst kürzlich diskutiertNun, das heißt:
Die Internettools von Jaws, der WebWizard und der Webformator haben
Tastenkombinationen integriert, die es ermöglichen Textblöcke zu
überspringen. Wenn ich die Funktion zu Beginn einer Linkliste, die von
nicht mehr als einer gewissen Anzal von Zeichen (Programmabhängig einstellbar
und in der Regel auf 25 bzw. 50 Zeichen festgelegt) unterbrochen ist, dann
springt mir der Fokus auf den Nächsten Textblock in dem mehr als die
eingestellte Zahl an Zeichen nicht von einem Teil eines Links
unterbrochen ist. Das System funktioniert bei Jaws auch sehr gut zum Überspringen
einer Tabelle (wie es beim Webformator aussieht kann Dir Günter Hanke besser
erzählen).Angenommen ein umfangreiches Dokument hat neben der
dokumentübergreifenden Navigation zusätzlich ein entsprechend
umfangreiches dokumentinternes Inhaltsverzeichnis. Wieso ist es in dem
Falle unklug, einen Link zum Überspringen der Navigation und
gegebenenfalls des Inhaltsverzeichnisses anzubieten? Es ging hier zwar
um eine sinnvolle Seitenstruktur und Navigation, zweifellos sollte die
Navigation übersichtlich gehalten werden,
aber die Frage stellt sich selbst dann, wenn die Navigation "nur" fünf
bis acht Einträge und das Inhaltsverzeichnis drei bis fünf Einträge
umfasst.Aus meiner Sicht kommen eben zwei oder mehr Links dazu, sodaß das Menü
noch länger wird als es eh schon ist. Mich haben die beiden Links au der
Homepage von Jan etwas irritiert, weil ich sowas noch nie zuvor gesehen habe und
deshalb vielleicht auch die etwas schlechte kritik.Viele stellen Navigation und Inhaltsverzeichnis ans Ende der Seite mit
dem Argument, dass der Besucher nicht die komplette Navigation lesen
muss, bevor er zum Inhalt kommt. Durch ein CSS-Layout erscheinen beide
dennoch neben dem eigentlich Inhalt. In solchen Fällen wird oft
bedauernswerterweise am Dokumentanfang kein Link zur Navigation am
Dokumentende gelegt. Wenn man sie an den Seitenanfang legt ist es doch
naheliegend, dass man sie überspringbar macht, auch alleine um dieser
Beobachtung gerecht zu werden.Nun, wie geschrieben mit den drei meistverbreitesten Tools stellen
Linklisten zur Navigation zu Beginn einer Seite ken grobes Problem da,
weil sie übersprungen werden können. Um zur Navigationsleiste am Ende zu
kommen gibt es auch Möglichkeiten wie den Windows Befehl "STRG+Ende" um zum
Dokumentende zu springen und dann von unten nach oben zu lesen.
Ausserdem bieten die Tools der Screenreaderhersteller die Möglichkeit sich
Linklisten der Seiten erstellen zu lassen und man kann dann relativ schnell die
Liste durchlesen ohne den eigentlichen Text auf der Seite lesen zu müssen.Ciao
MichaelBarrierefreies Internet Mailing-Liste
Fraunhofer-Institut für Angewandte Informationstechnik
http://access.fit.fraunhofer.de/
---Mathias
-
-
-
-
-
-
-
-
-