HTML 5

Autor: Markus Fettke | Kategorie: WebTechnik

HTML 5 soll das bestehende HTML um “Rich Web Content” erweitern. Neue Schnittstellen, um zweidimensionale Grafiken zu zeichnen, die bessere Einbettung von Video- und Audioinhalten sowie zahlreiche neue Elemente zur besseren Auszeichnung in HTML-Seiten sind die Besonderheiten von HTML 5. Zudem hält die Spezifikation neue Möglichkeiten für Web-Applikationen bereit.

Neue Attribute

async auf script, um das Laden und Ausführen von Skripten zu steuern
autocomplete, list, min, max, multiple, pattern und step auf input
autofocus auf button, input (sofern nicht hidden), select und textarea, um Fokus auf Formularelemente zu legen
charset auf meta, um Encoding anzugeben
(color, date, datetime, datetime-local, email, month, number, range, search, tel, time, url und week als @type-Werte auf input, um Nutzern und Autoren das Leben einfacher zu machen)
disabled auf fieldset, um einen ganzen Formularabschnitt zu deaktivieren
form auf button, fieldset, input, output, select und textarea, um Formularelemente mit Formularen zu assoziieren (da diese außerhalb von Formularen plaziert werden können)
formaction, formenctype, formmethod, formnovalidate und formtarget auf button und input, um entsprechende form-Pendants zu überschreiben
hreflang und rel auf area zwecks Konsistenz mit a und link
label und type auf menu, um weitere UI-Varianten zu ermöglichen
manifest auf html, um auf ein »Cache-Manifest« zu verweisen (⇾ Offline-Webanwendungen)
media auf a und area zwecks Konsistenz mit link
novalidate auf form, um etwaige Formulardatenvalidierung zu überspringen
ping auf a und area, das eine leerzeichenseparierte Liste von URLs akzeptiert, die gepingt werden, wenn Link gefolgt wird
placeholder auf input und textarea
required auf input (sofern nicht hidden oder ein Button) und textarea, um Pflichtfelder anzugeben
reversed auf ol, um die Listenreihenfolge zu invertieren
sandbox und seamless auf iframe, um Inhalte (aus Sicherheitsgründen) zu »sandboxen«, wie beispielsweise Kommentare
scoped auf style, um »spezifischere« Stylesheets zu ermöglichen
sizes auf link, um Icon-Größen anzugeben
start auf ol (wieder gestattet)
target auf a und area (wieder gestattet)
target auf base zwecks Konsistenz mit a
value auf li (wieder gestattet)

HTML 5 und Performance

Einfacher und kürzer: DTD (<!DOCTYPE html>), Encoding (<meta charset=”utf-8″>), MIME-Typen (<style>, <script>, …)

async und defer zur kontrollierteren Skriptausführung
Ohne async und defer: Sofortiges Laden der Skripte, wobei restliches Laden verlangsamt werden kann
defer (bereits Teil von HTML 4): »Skript verändert nicht das DOM, bitte weitermachen mit Parsen und Rendern«
async: »Skript kann ausgeführt werden, sobald verfügbar«
Auslassen optionaler Tags kann über 20 % Dateigröße einsparen
<!DOCTYPE html> wird unterstützt (ruft in anderen Schreibweisen aber nicht unbedingt konsistent Standards Mode hervor)
<meta charset=”"> funktioniert ebenso wie einige zuvor proprietäre Elemente oder Attribute (wie embed oder @autocomplete)
Neue Elemente können eingesetzt und mittels document.createElement(‘element’); auch im Internet Explorer »stylebar« gemacht werden
Validierer sind vorhanden: validator.nu, validator.w3.org
Erfahrungen sammeln, Feedback geben: public-html-comments@w3.org, whatwg@whatwg.org

Quelle: golem.de, meiert.com

Tags: , ,

Weiter | Kommentare (0) | 31 Oktober 2009

OpenID

Autor: Markus Fettke | Kategorie: WebTechnik

OpenID ist ein so genanntes Single Sign-on-System für Webseiten und andere webbasierte Dienste, welches als Protokoll seit 2005 existiert. Nutzer können sich bei einem OpenID-Provider einmal anmelden und so eine Identität erstellen und sich mit dieser OpenID ohne Benutzername oder Passwort bei allen anderen Systemen und Diensten anmelden, die OpenID angeschlossen sind.

OpenID provider

  • Google: (https://www.google.com/accounts/o8/id) a user’s Google Account can be used as an OpenID (via Blogger URL, e.g. http://username.blogspot.com[1] or by entering[2]) – now the feature has been removed from blogger
  • Yahoo!: a user’s Yahoo! account can be used as an OpenID, however it does not accept the credentials of third-party websites to work with their own services[3]
  • Flickr: (http://flickr.com/photos/username) | a user’s Flickr account can be used as an OpenID, this now redirects to Yahoo’s OpenID login.
  • Microsoft (pending)[4]
  • AOL: (openid.aol.com/screenname) a user’s AOL or AIM account can be used as an OpenID (e.g. )
  • MySpace myspace.com or myspace.com/username may be used as the URL identifier
  • LiveJournal
  • i-name providers, accredited by XDI.org all provide OpenID service for global (paid) or community (free) i-names.
  • Virgilio.it: a user’s Virgilio account can be used as an OpenID.
  • clavid.ch: Independent Swiss OpenID-Provider supporting several authentication types such as Swiss Post Certificate, AXSionics
  • InternetPassport, YubiKey, Username/Password or One-Time-Passwords.
  • OpenID France First french free OpenID provider hosted by the association
  • FUPEI
  • Identity.net: OpenID issuer that integrates attribute verification and portable reputation
  • MyOpenID: First standalone OpenID provider, Authored OSS libraries, Full Platform solutions.
  • myID.net: Korean OpenID provider by Openmaru Studios
  • IDtail: OpenID Provider by AhnLab (Korean)
  • Daum OpenID: Korean OpenID provider by Daum.net
  • Beemba: Beemba – OpenID plus Social aggregation with services like Twitter, FriendFeed, Pownce and a ton more!
  • Clickpass: OpenID provider that makes OpenID easier for developers to install and users to understand
  • isOpenID: Russian OpenID provider
  • Openminds: first Belgian OpenID Server
  • GetOpenID
  • ClaimID
  • LiquidID OpenID with email aliasing that delivers less spam & safer logins.
  • Weblogs SL :: OpenID: OpenID Provider by Weblogs SL (in Spanish).
  • Beta ID: OpenID Provider by Betazeta Netwoks (in Spanish)
  • LuxSci: OpenID and Secure Email Provider
  • ICY OpenID: South African OpenID Provider
  • Yandex: Leading Russian search engine
  • EEnga/OpenID – OpenID provider with simple handling and link to FaceBook (in German)
  • MeinGuter.Name – OpenID provider with SSL secured connection (in German)
  • my.xlogon.net – OpenID provider with multiple identities, multiple persons, only SSL secured connections and anti phishing support (in German)
  • yiid.com – your internet ID – openID provider and client, bietet provied configuration options of the own online identities

Ein bekannter OpenID-Anbieter ist zum Beispiel Facebook. Als Nutzer legen Sie dort einen Account an und können diesen dann mit anderen OpenID-Diensten wie MySpace oder Yahoo! verknüpfen.

Das hat den Vorteil, dass man lediglich einen Button klicken muss, um Zugriff auf einen Dienst zu erhalten – das heißt Nutzer müssen sich nicht eine Menge verschiedener Accounts und deren Zugangsdaten merken. Das ist eine deutliche Erleichterung für die Nutzer.

OpenID ist dezentral und basiert auf der Idee, dass eine Identität über einen URL – bei Facebook sind die URLs zum Beispiel “http://www.facebook.com/Ihr_Name”. Andere Dienste verwenden Subdomains. Da unter Facebook viele Nutzer gleiche Namen besitzen, verwendet Facebook mittlerweile einen Mix aus Subdomain, in welcher in der Regel die Länderkennung steckt sowie einem Pfad mit Ihrem Namen. Beim Verknüpfen ihrer Identität mit einem neuen Service, wird auf diese Identität zurückgegriffen.

Eine OpenID-Identität wird angelegt, sobald Sie sich ein Benutzerkonto bei einem Dienst etwa wie Facebook oder MySpace anlegen. Es steht ihnen jedoch frei, diese Identität auch mit anderen Diensten zu verknüpfen. Wenn Sie ihr Konto mit einem neuen Dienst verknüpfen wollen, wird die Authentifizierung – also der Login über den ursprünglichen OpenID-Anbieter, bei dem Sie ihre Identität angelegt haben, abgewickelt.

OpenID hat Unterstützung von Branchenriesen wie Google, IBM und Microsoft erfahren. Bisher war es jedoch nicht möglich, etwa eine MySpace OpenID-Identität für einen neuen Facebook-Account zu nutzen – wohl weil MySpace und Facebook direkte Wettbewerber sind. Im Frühjahr 2009 kündigte Facebook die vollständige Implementierung von OpenID an.

Es gibt zahlreiche Sicherheitsbedenken die mit OpenID verbunden sind. So sollte man sich die Frage stellen, was mit einer Identität passiert, wenn der Provider den Dienst einstellt. Auch könnte man die Gefahr wähnen, dass Aufsichtsbehörden oder kommerzielle Anbieter Nutzerverhalten leichter überwachen können. Die Gefahr von Phishing-Attacken ist offensichtlich, da diese umso lukrativer je mehr Accounts mit einer OpenID verknüpft sind. Marco Slot zeigt in einem kleinen Tutorial wie einfach das Phishing mit ein wenig PHP ist. Andererseits können Nutzer leichter die Authentizität von OpenID Diensten ermitteln, da der Login und die Authentifizierung jedes neuen Dienstes über den Login des ursprünglichen OpenID-Providers, bei welchem die Identität angelegt wurde, erfolgt. Mehr Sicherheit sollen zudem die Verwendung von Cookies und Captchas, sowie die clientseitige Verwendung von TLS-Zertifikaten zur Athentifizierung bringen.

Insgesamt bietet OpenID Chancen, um das Internet vor allem benutzerfreundlicher zu machen. Es erlaubt die Verschmelzung von Diensten und das einfachere Verwalten von Benutzerkonten, da so eigentlich nur noch eine Identität verwaltet werden muss. Leider, wie jede Technologie, gibt es Bedenken und Risiken. ™

Quelle: drweb.de

Tags: ,

Weiter | Kommentare (0) | 27 Oktober 2009

Cascading Style Sheets

Autor: Markus Fettke | Kategorie: WebTechnik

Das World Wide Web Consortium (W3C) entwickelte CSS, um zum ursprünglichen Grundgedanken von HTML zurückzukehren: die Trennung der Informationen von der Präsentation. Ohne CSS ist HTML für Inhalt, Struktur und Aussehen zuständig. Ein aufgeblähter und unübersichtlicher Code entsteht.

Mit CSS ist HTML hauptsächlich mit der Struktur eines Dokumentes beschäftigt, CSS dagegen ist für das Aussehen verantwortlich.

Über CSS kann eine wesentlich schlankere Seite (Downloadzeiten) in kürzerer Zeit (warum irgend etwas doppelt angeben?) erstellt werden – und das für alle Einzelseiten einer Homepage. Änderungen am Design sind innerhalb kürzester Zeit erledigt.

Vor- und Nachteile von Cascading Style Sheets

  • Größere Layoutmöglichkeiten:
    Das Design ist konsistent zwischen den Browser (siehe unten).
  • Kürzere Zeiten
    zur Erstellung und Pflege von Homepages: Von einer einzigen Datei aus kann ein komplettes Homepage-Design erstellt und bei Bedarf geändert werden.
  • Schnellere Übertragung:
    CSS macht zahlreiche HTML-Wiederholungen überflüssig. Weniger Code bedeutet schnelleren Download.
  • Homepage funktioniert auch noch bei alten Browsern:
    Auch bei Browsern, die CSS nicht unterstützen, wird die Homepage noch angezeigt (allerdings dann ohne CSS-Design).
  • Unterschiedliche Unterstützung durch Browser:
    Größter Nachteil ist die teilweise uneinheitliche Unterstützung durch Browser. Deshalb sollten nicht alle CSS-Definitionen eingesetzt werden.

Über CSS können die Formatierungen einfach und elegant vorgenommen werden. So können z. B. Schriftattribute wie Farbe, Schriftart und Abstände bequem eingestellt werden. CSS sind vergleichbar mit den Formatvorlagen bei Word.

Das Besondere an CSS ist, dass diese “Formatierungen” durch Auslagerung dann einfach für alle Seiten einer Homepage gelten. Dementsprechend werden Änderungen nur noch an einer zentralen Stelle durchgeführt und können auf alle Seiten einer Homepage Auswirkungen haben (wird erst weiter hinten gezeigt).

CSS ist in der Version 1 so weit verbreitet, dass es problemlos eingesetzt werden kann. Das Besondere an CSS ist, dass Browser, die kein CSS kennen, absolut kein Problem mit CSS haben. Alte Browser ignorieren CSS einfach und der Seitenaufbau funktioniert trotzdem. CSS greift nicht in die HTML-Befehle ein, sondern wird darüber gelegt.

Quelle: html-seminar.de

Tags: ,

Weiter | Kommentare (0) | 27 Oktober 2009

HTTP-Status-Codes

Autor: Markus Fettke | Kategorie: WebTechnik

100 Continue
Fortfahren. Wird derzeit noch nicht verwendet.

101 Switching Protocols
Protokoll wechseln. Wird derzeit noch nicht verwendet.

200 OK
Der Server kann die angeforderten Daten wie gewünscht versenden. Dies ist der Normalfall, wenn keine Probleme auftauchen. Der größere Anteil aller Anfragen an den Webserver sollte mit diesem Status-Code enden – ansonsten stimmt etwas nicht.

201 Created
Ein Objekt (z.B. eine Datei oder ein Verzeichnis) wurde auf dem Server erfolgreich angelegt. Das kann vorkommen, wenn die Anfrage des Browsers an den Server mit einer der HTTP-Übertragungsmethoden post oder put erfolgte und eine Anweisung zum Erstellen des entsprechenden Objekts enthielt.

202 Accepted
Der Server hat die Anfrage des Browsers akzeptiert, liefert aber keine Daten als Antwort. Der Server schreibt die Daten statt sie zu senden in eine Datei und teilt in der Meldung mit, wo die Daten später zu finden sein werden. Diese Meldung sagt nichts darüber aus, ob der Server die Anfrage erfolgreich behandeln kann. Er hat sie einfach nur akzeptiert und die Abarbeitung auf einen späteren Zeitpunkt verschoben.

203 Non-Authoritative Information
Dieser Status-Code sollte von einem Server anstelle von 200 zurückgegeben werden, wenn es sich nicht um den Original-Server handelt, sondern beispielsweise um einen Proxy-Server. Der Web-Browser erfährt auf diese Weise, dass die Daten erfolgreich gesendet werden konnten, aber nicht vom Original-Server kommen und daher keine Garantie auf deren Aktualität besteht.

204 No Content
Der Server hat die Anfrage erhalten, sendet jedoch keine Daten zurück. Gut verwendbar ist dieser Status-Code bei Verwendung in CGI-Scripts, die zwar etwas auf dem Server erledigen, aber keinen neuen HTML-Code an den aufrufenden Browser senden wollen. Aus Sicht des Anwenders bleibt der alte Bildschirminhalt bestehen.

205 Reset Content
Der Server hat die Anfrage ausgeführt, muss aber keine Daten zurücksenden. Stattdessen sollte der Browser den Bildschirminhalt, der zu der Anfrage geführt hat, zurücksetzen. Das ist vor allem im Zusammenhang mit serverseitigen Skripten sinnvoll, wenn der Benutzer mehrere Eingaben über das gleiche Formular machen soll, und sich dieses zwischenzeitlich nicht ändert.

206 Partial Content
Der Client hat nur einen Teil der Daten angefordert und der Server versendet diese wie gewüscht. Mit Angaben zu content-length (z.B.: 1024) und content-range (z.B.: bytes 0-1023/1024) wird angegeben, wie viele Bytes von dem angeforderten Inhalt geliefert werden, und welcher Teil der Gesamtdaten. Das passiert zum Beispiel, wenn ein vorangegangener Download unterbrochen wurde und der Client an der Abbruchstelle erneut mit dem Herunterladen beginnt.

300 Multiple Choices
Die angeforderten Daten liegen in mehreren verschiedenen Ausführungen vor. Anstelle der Daten werden die verfügbaren URIs und ihre Eigenschaften (zum Beispiel Sprache oder MIME-Typ) als Liste übertragen. Der Web-Browser kann den Anwender anschließend in einem Dialog einen URI auswählen lassen oder die Auswahl automatisch treffen.

301 Moved Permanently
Die angeforderten Daten befinden sich nicht mehr unter dem URI, sie wurden dauerhaft auf eine andere Adresse verschoben. In der Statusmeldung wird angegeben, unter welchem URI sich die Daten jetzt befinden. Ein Web-Browser, der diese Antwort vom Server erhält, kann beispielsweise gleich die neue Adresse anfordern.

302 Moved Temporarily
Die angeforderten Daten wurden vorübergehend zu einem anderen URI verschoben. In der Statusmeldung wird angegeben, unter welcher Adresse sich die Daten derzeit befinden. Ein Web-Browser, der diese Antwort erhält, kann beispielsweise gleich die temporär gültige Adresse anfordern.

303 See Other
Die angeforderten Daten sind unter einem angegebenen URI verfügbar und sollten von dort mit Hilfe der get-Methode angefordert werden. Dieser Status-Code ist für CGI-Scripts gedacht, die mit der post-Methode aufgerufen wurden und den Browser auf eine andere Ressource lenken wollen, die mit der get-Methode angefordert werden soll.

304 Not Modified
Die angeforderten Daten haben sich seit dem angegebenen Zeitpunkt nicht geändert und werden deshalb nicht gesendet. Dieser Status-Code ist neben dem Code 200 einer der häufigsten in der Praxis. Er tritt auf, wenn ein moderner Webbrowser, der die Daten noch im Cache hat, eine Anfrage an den Server sendet und dabei den Ladezeitpunkt der Daten in seinem Cache übermittelt. Stellt der Server dann fest, dass sich die Daten seit dem angegebenen Zeitpunkt nicht geändert haben, braucht er sie nicht noch einmal zu übermitteln, sondern sendet nur diesen Statuscode und keine Daten. Der Browser holt daraufhin seine alte Version aus dem Cache.

305 Use Proxy
Die angeforderten Daten sollen statt von diesem Server von dem in der Statusmeldung angegebenen Proxy-Server angefordert werden.
306 [Unused] Reserviert. Wird derzeit aber nicht verwendet.

307 Temporary Redirect
Wie Status-Code 302. Gedacht für Fehlreaktionen einiger Browser auf 302.

400 Bad Request
Die Anfrage enthält Syntaxfehler. Der Server kann die Anfrage deshalb nicht bearbeiten. Das kann beispielsweise vorkommen, wenn der verwendete Browser einen Programmierfehler aufweist und ungültige Anfragen sendet, oder ein Mensch versucht, händisch (also etwa mit telnet) mit dem Server zu kommunizieren und dabei einen Fehler macht.

401 Unauthorized
Die angeforderten Daten sind zugangsgeschützt. Der Server kann die Daten nur senden, wenn eine gültige Zugangskennung, bestehend aus Benutzername und Passwort, bei der Anfrage mit gesendet wird. Das passiert in der Praxis immer dann, wenn eine Adresse aufgerufen wird, die z.B. durch Seite htaccess zugangsgeschützt ist. Der Web-Browser zeigt dann, nachdem er diesen Status-Code erhalten hat, einen Dialog zum Eingeben von Benutzername und Kennwort an. Mit den eingegebenen Daten startet er dann eine neue Anfrage an den Server.

402 Payment Required
Die angeforderten Daten sind kostenpflichtig. Der Server kann die Daten nur senden, wenn eine Bestätigung der Zahlung für die Daten bei der Anfrage mitgesendet wird. Derzeit wird dies aufgrund fehlender einheitlicher technischer Grundlagen für Micropayment noch nicht verwendet.

403 Forbidden
Der Server möchte die angeforderten Daten nicht herausgeben. Das passiert zum Beispiel wenn der Zugriff auf die Ressource von dem IP-Adress-Bereich, aus dem die Anfrage kommt, in der Serverkonfiguration verboten wurde, die Ressource ganz und gar gesperrt wurde oder man versucht, ein Verzeichnislisting zu bekommen, dies jedoch in der Serverkonfiguration abgeschaltet wurde. Dies ist ein anderer Status als 401! Weder die Eingabe eines Passwortes noch das Wiederholen der Anfrage wird etwas bewirken.

404 Not Found
Der angeforderte URI existiert nicht. Dies ist neben den Status-Codes 200 und 304 einer der häufigsten Fälle in der Praxis. Er tritt immer dann ein, wenn ein Verweis auf eine nicht oder nicht mehr existierende Adresse auf dem Server führt, oder wenn der Anwender versucht hat, eine Adresse auf dem Server durch händisches Eintippen in der Adresszeile des Browsers aufzurufen, diese Adresse aber nicht existiert.

405 Method Not Allowed
Die angegebene Übertragungsmethode ist auf dem Server nicht erlaubt. Die Daten werden deshalb nicht übertragen. Das kann beispielsweise vorkommen, wenn in der Konfiguration des Webservers außer der get-Methode keine weitere Methode erlaubt ist, ein HTML-Formular aber einen CGI-Aufruf mit der post-Methode enthält.

406 Not Acceptable
Die Anfrage ist in dieser Form nicht akzeptabel. Die Daten werden deshalb nicht übertragen.

407 Proxy Authentication Required
Die Anfrage soll über einen Proxy-Server geleitet werden. Der Proxy-Server ist aber zugangsgeschützt und leitet Anfragen erst nach dem Erhalt einer gültigen Zugangskennung weiter, die in der Regel aus Benutzername und Passwort besteht. Beim Erhalt dieses Status-Codes verhält sich der Client ähnlich wie beim Status-Code 401, mit dem Unterschied, dass die Authentifizierung für den Proxy-Server gilt und nicht für den Zielserver. Das wird in der Praxis zum Beispiel in größeren Installationen wie Firmen oder Universitäten eingesetzt, wo der Zugriff auf das Intranet frei ist, nach aussen gehende Anfragen aber bestimmte Berechtigungen benötigen und zwangsweise durch einen Proxy-Server geleitet werden.

408 Request Timeout
Der Server hat eine erwartete Anfrage nicht innerhalb des dafür festgelegten Maximalzeitraums erhalten. Die Verbindung zum anfragenden Browser wird deshalb abgebaut. Angeforderte Daten werden nicht übertragen.

409 Conflict
Der Server kann die angeforderten Daten nicht senden, weil ein Konflikt mit einem anderen Prozess aufgetaucht ist. Das kann beispielsweise passieren, wenn ein anderer Prozess eine angeforderte Datei gerade mit einem exklusiven File-Locking (keinerlei Dateizugriff für andere Prozesse erlaubt) versehen hat.

410 Gone
Die angeforderten Daten wurden zu einem anderen URI verschoben. Dem Server ist aber nicht bekannt, wohin. Deshalb kann er sie nicht senden – andernfalls würde ein Status-Code 301 oder 302 gesendet worden.

411 Length Required
Die Daten werden nicht gesendet. Sie können nur gesendet werden, wenn die Anfrage eine Angabe zu content-length enthält. Der Browser kann versuchen, die Anfrage neu zu formulieren und dabei die Länge der an den Server gesendeten Anfragedaten mit zu übermitteln.

412 Precondition Failed
Eine oder mehrere Bedingungen, die bei der Anfrage gestellt wurden, treffen nicht zu. Die angeforderten Daten werden deshalb nicht übertragen.

413 Request Entity Too Large
Der Server kann die Anfrage nicht bearbeiten, weil diese zu viele Zeichen enthält. Die angeforderten Daten werden deshalb nicht übertragen.

414 Request-URL Too Long
Der Server kann die Anfrage nicht bearbeiten, weil die angeforderte Adresse zu viele Zeichen enthält. Die angeforderten Daten werden deshalb nicht übertragen.

415 Unsupported Media Type
Der Server will die Anfrage nicht bearbeiten, weil der Seite MIME-Typ, den der Client in der Anfrage verwendet hat, für diese Anfrage nicht unterstützt wird. Die angeforderten Daten werden deshalb nicht übertragen.

416 Requested Range Not Satisfiable
Die Anfrage enthält Angaben, welcher Byte-Bereich von dem angeforderten URI übertragen werden soll. Sowohl der Anfangswert als auch der Endwert des angegebenen Bereichs liegen außerhalb des verfügbaren Byte-Bereichs, z.B. wenn ein Byte-Bereich von 1000 bis 2000 angegeben wird, die Ressource aber nur 500 Byte hat. Die angeforderten Daten werden deshalb nicht übertragen.

417 Expectation Failed
Die Anfrage enthält im expect-Feld bestimmte Wünsche, die der Server nicht erfüllen kann. Die angeforderten Daten werden deshalb nicht übertragen.

500 Internal Server Error
Der Server kann die angeforderten Daten nicht senden, weil auf dem Server ein Fehler aufgetreten ist. Beispielsweise konnte das aufgerufene CGI-Script nicht gestartet werden.

501 Not Implemented
Die Anfrage enthält Anforderungen, die der Server nicht bearbeiten kann, weil die Voraussetzungen dazu nicht implementiert sind. Die angeforderten Daten können deshalb nicht gesendet werden.

502 Bad Gateway
Zum Bearbeiten der Anfrage musste der Server einen anderen Server aufrufen, erhielt dabei jedoch eine Fehlermeldung. Die angeforderten Daten können deshalb nicht gesendet werden.

503 Service Unavailable
Der Server kann die Anfrage wegen Überlastung nicht bearbeiten. Die angeforderten Daten können deshalb nicht gesendet werden. In der Statusmeldung kann stehen, wann die Anfrage frühestens wieder bearbeitet werden kann. Im Gegensatz zum Status-Code 202 verarbeitet der Server die Daten nicht, sobald er wieder Kapazitäten hat.

504 Gateway Timeout
Zum Bearbeiten der Anfrage musste der Server einen anderen Server aufrufen, erhielt dabei jedoch nach einem festgelegten Maximalzeitraum keine Antwort. Die angeforderten Daten können deshalb nicht gesendet werden.

505 HTTP Version Not Supported
Der Server unterstützt die im HTTP-Header der Anfrage angegebene HTTP-Version nicht. Die angeforderten Daten werden deshalb nicht gesendet.

Quelle: selfhtml.org

Tags:

Weiter | Kommentare (0) | 27 Oktober 2009

.htaccess

Autor: Markus Fettke | Kategorie: WebTechnik

ist eine Konfigurationsdatei des Webservers. Bei einem Aufruf einer Webseite geht der Webserver gemäß dieser Konfiguration (den Einträgen in der .htaccess) vor. Die Konfiguration beinhaltet z.B. Zugriffsrechte auf einzelne Dokumente oder Verzeichnise, Fehlermeldungen usw.

Die .htaccess-Datei kann mit einem Texteditor (z.B. Notepad) erstellt werden. Sie muss dann (im ASCII-Modus) auf den Server hochgeladen werden. Nach dem Hochladen muss die Datei auf dem Server für alle lesbar sein. Die Zugriffsrechte müssen auf CHMOD 644 eingestellt werden.

Passwortschutz

.htaccess-Dateien sind verzeichnisspezifisch. Speichern Sie die .htaccess-Datei also in demjenigen Verzeichnis ab, in dem die zu schützenden Daten liegen. Sie können wahlweise das ganze Verzeichnis mit all seinen Unterverzeichnissen oder nur bestimmte Dateien oder Dateitypen schützen. Sie können den Passwortschutz außerdem wahlweise für einzelne Benutzer oder für ganze Benutzergruppen einrichten. Auch Kombinationen beider Formen sind möglich. Damit der Verzeichnisschutz mit Passwort funktioniert, genügt die .htaccess-Datei alleine allerdings nicht. Sie brauchen zusätzlich eine Datei, in der die Benutzernamen und die zugehörigen Passwörter stehen. Falls Sie mit Benutzergruppen arbeiten, benötigen Sie außerdem noch eine Datei, in der die Benutzergruppen definiert werden.

Anwendungen einer

.htaccess-Datei

# .htaccess-Datei für WebVerzeichnis /office
AuthType Basic
AuthName “office-Bereich”
AuthUserFile /usr/office/web/.htusers
AuthGroupFile /usr/office/web/.htgroups
Require user Heiko Peter Frank
Require group office

.htusers-Datei unter Unix

# BenutzerDatei
Heiko:IN8//m5KMwIce
Peter:69gY8YPjeN63t
Frank:INw2mPEH.owe2

.htusers-Datei unter Windows

# BenutzerDatei
Heiko:meinpasswort
Peter:kannmansehen
Frank:unterwindows

.htgroups-Datei

# GruppenDatei
office: Heiko Peter Frank

Tags:

Weiter | Kommentare (0) | 27 Oktober 2009

mod_rewrite

Autor: Markus Fettke | Kategorie: WebTechnik

Sicherlich am häufigsten trifft man mod_rewrite auf Internetseiten, die eine gute Platzierung in Suchmaschinen erreichen möchten und mod_rewrite dazu verwenden den Suchmaschinen-Robotern (den sog. “Spidern”) mit Hilfe von mod_rewrite statische Dokumente “vorgaukeln”.

Moderne Suchmaschinen sind zwar in der Lage dynamisch erzeugte Seiten (index.php?seite=12&inhalt=3&foo=bar) zu indizieren und in den Index aufzunehmen, jedoch haben auch sie gewisse Schwierigkeiten wenn die Anzahl der übergebenen Parameter zu gross wird. Yahoo, MSN und Google indizieren dynamisch erzeugte Dokumente z.B. nur wenn die Wertigkeit der Seite hoch genug ist und die Anzahl der Parameter eine gewisse Grenze nicht überschreitet.

Statische Webseiten werden von Suchmaschinen in der Tat sichtlich vollständiger und besser in den Suchergebnissen, z.B. bei Google, Yahoo, MSN, platziert als dynamische Seiten mit einer Vielzahl von Parametern.

Zudem gibt es auch kleinere oder Spezialsuchmaschinen die mit den URL-Parametern noch sichtliche Probleme haben. Dennoch könnte es für den ein oder anderen Seitenbetreiber von Bedeutung sein seine Webseite auch hier gelistet zu haben.

Anwendungen von mod_rewrite

mod_rewrite ist ein praktisches Werkzeug für Webmaster, Service Provider und Administratoren. Die Einsatzgebiete dieses wertvollen Moduls sind extrem vielseitig.

Anwendungsbeispiele:

  • Suchmaschinenoptimierung / Suchmaschinenfreundliche URL’s
  • Spambots ausschliessen (und damit Guestbook-Spam, Blog-Spam, Foren-Spam eindämmen oder ganz verhindern)
  • Schutz vor “Hackern” und/oder “Script-Kiddies”
  • Content-Klau verhindern
  • Weiterleitung oder Sperrung nach bestimmten Client-Kriterien wie z.B. Referer, Client, IP-Adresse, etc.
  • Content-Regeneration bei Umstrukturierung der Webseite(n)
  • Zeitabhängige Weiterleitungen
  • Dynamische Mirrors

Quelle: modrewrite.de

Tags:

Weiter | Kommentare (0) | 27 Oktober 2009