Dateitransfer
mit HTTP| Shamrock > Support > DFÜ > Internet | [ Sitemap | Suche | Kontakt ] |
Dieser Abschnitt zeigt, wie Internet-Browser Informationen aus dem World Wide Web (WWW) per HTTP anfordern, wie HTML-Seiten grundsätzlich aufgebaut sind, wie man sie mit Script-Sprachen aufbohren kann und welche anderen Dienste es im Internet noch gibt. Mehr über das dabei benutzte TCP/IP-Protokoll und damit zusammenhängende Themen finden Sie in den Abschnitten Netzwerke sowie Geschichte der Kommunikation.
Dateitransfer
mit HTTPDas Hypertext Transfer Protocol, kurz HTTP, kennt jeder Internet-Benutzer schon von dem "http://", mit dem jede Adresse im World Wide Web beginnt. Damit weiß der Browser, welches Protokoll er benutzen muss, um Inhalte von einem bestimmten Server abzurufen - HTML-Seiten, Grafiken und sonstige Daten. In diesem Kapitel wird gezeigt, welches ganz einfache und leicht nachvollziehbare Verfahren dem HTTP-Protokoll zugrunde liegt.
| Die Themen dieses Abschnitts: | Web-Adressen HTTP/1.0 HTTP/1.1 |
SSL, DES Server-Log RFC-Standards |
Bevor wir technische Details besprechen, zunächst noch ein kleiner Ausflug
zum Aufbau von Web-Adressen. Sicher ist Ihnen schon aufgefallen, dass deutsche
Adressen üblicherweise www.irgendwer.de lauten. Dahinter kann
noch eine Seitenangabe stehen, zum Beispiel www.shamrock.de/dfu/index.htm. In
der Adresszeile des Browsers lautet die Angabe in diesem Fall vollständig so:
http://www.shamrock.de/dfu/index.htm
Diese Zeile besteht aus folgenden Bestandteilen:
| http:// www. shamrock .de /dfu/ index.htm |
Übertragungs-Protokoll, hier HTTP Subdomain bzw. Rechnername, hier www = Web-Server Üblicherweise ein Firmen- oder Eigenname Top-Level-Domain, hier de=Deutschland Verzeichnis, wo die gewünschte Datei zu finden ist Name der gewünschten Datei |
Bei Domain-Namen spielt Groß- oder Kleinschreibung keine Rolle, shamrock.de kann also auch Shamrock.De geschrieben werden. Vorsicht: Im Gegensatz dazu reagieren Unix-/Linux-Webserver empfindlich auf eine abweichende Groß-/Kleinschreibung bei Verzeichnis- und Dateinamen, index.htm ist hier etwas anderes als INDEX.htm!
Die folgenden zwei Tabellen nennen Top-Level-Domains (TLD), die bestimmten Ländern zugewiesen sind, sowie landesunabhängige wie .com oder .int. In einigen Fällen wird eine landesspezifische TLD wie etwa .tv für einen namensgleichen Geschäftsbereich (hier TV = Fernsehen) verwendet, auch wenn die jeweilige Firma ihren Sitz keineswegs in Tuvalu hat.
| ac=Ascension-Inseln ad=Andorra ae=Verein.Ar.Emirate af=Afghanistan ag=Antigua ai=Anguilla al=Albanien am=Armenien an=Niederl.Antillen ao=Angola aq=Antarktis ar=Argentinien as=Amerik. Samoa at=Österreich au=Australien aw=Aruba az=Aserbeidschan ba=Bosnien-Herzeg. bb=Barbados bd=Bangladesch be=Belgien bf=Burkina-Faso bg=Bulgarien bh=Bahrain bi=Burundi bj=Benin bm=Bermuda bn=Brunei bo=Bolivien br=Brasilien bs=Bahamas bt=Bhutan bv=Bouvet-Insel bw=Botswana by=Belarus bz=Belize ca=Kanada cc=Cocos-Inseln cd=Kongo cf=Zentralafrik.Rep. cg=Kongo ch=Schweiz ci=Elfenbeinküste ck=Cook-Inseln cl=Chile cm=Kamerun cn=China co=Kolumbien cr=Costa Rica cu=Kuba cv=Cap Verde cx=Weihnachtsinsel cy=Zypern cz=Tschechien de=Deutschland dj=Dschibuthi dk=Dänemark dm=Dominica do=Dominikan. Rep. dz=Algerien ec=Ecuador ee=Estland |
eg=Ägypten eh=West-Sahara er=Eritrea es=Spanien et=Äthiopien eu=Europa fi=Finnland fj=Fiji-Inseln fk=Falkland-Inseln fm=Mikronesien fo=Faroe-Inseln fr=Frankreich ga=Gabun gd=Grenada ge=Georgien gf=Frz.-Guiana gg=Guernsey gh=Ghana gi=Gibraltar gl=Grönland gm=Gambia gn=Guinea gp=Guadeloupe gq=Äquat.-Guinea gr=Griechenland gs=Georgia+Sandw.I. gt=Guatemala gu=Guam gw=Guinea-Bissau gy=Guyana hk=Hong Kong hm=Heard/McDonald hn=Honduras hr=Kroatien/Hrvatska ht=Haiti hu=Ungarn id=Indonesien ie=Irland il=Israel im=Insel Man in=Indien io=Ind.Ozean/britisch iq=Irak ir=Iran is=Island it=Italien je=Jersey jm=Jamaica jo=Jordanien jp=Japan ke=Kenia kg=Kirgisistan kh=Kambodscha ki=Kiribati km=Komoren kn=St.Kitts+Nevis kp=Korea (Nord) kr=Korea (Süd) kw=Kuwait ky=Kaiman-Inseln kz=Kasachstan la=Laos |
lb=Libanon lc=Santa Lucia li=Liechtenstein lk=Sri Lanka lr=Liberia ls=Lesotho lt=Litauen lu=Luxembourg lv=Lettland ly=Libyen ma=Marokko mc=Monaco md=Moldawien me=Montenegro mg=Madagaskar mh=Marshall-Inseln mk=Mazedonien ml=Mali mm=Myanmar mn=Mongolei mo=Macau mp=Nördl. Marianen mq=Martinique mr=Mauretanien ms=Montserrat mt=Malta mu=Mauritius mv=Malediven mw=Malawi mx=Mexiko my=Malaysia mz=Mozambique na=Namibia nc=Neu Kaledonien ne=Niger nf=Norfolk-Insel ng=Nigeria ni=Nicaragua nl=Niederlande no=Norwegen np=Nepal nr=Nauru nu=Niue nz=Neuseeland om=Oman pa=Panama pe=Peru pf=Frz. Polynesien pg=Papua Neuguinea ph=Philippinen pk=Pakistan pl=Polen pm=St.Pierre/Miqelon pn=Pitcairn-Insel pr=Puerto Rico ps=Palästina pt=Portugal pw=Palau py=Paraguay qa=Qatar re=Reunion-Insel ro=Rumänien |
rs=Rep. Serbien ru=Russische Föd. rw=Ruanda sa=Saudi-Arabien sb=Solomon-Inseln sc=Seychellen sd=Sudan se=Schweden sg=Singapur sh=St. Helena si=Slovenia sj=Svalbard/J.Mayen sk=Slowakei sl=Sierra Leone sm=San Marino sn=Senegal so=Somalia sr=Surinam st=Sao Tome/Principe sv=El Salvador sy=Syrien sz=Swaziland tc=Turks.Ciacos I. td=Tschad tf=Frz. Süd-Territ. tg=Togo th=Thailand tj=Tadschikistan tk=Tokelau tm=Turkmenistan tn=Tunesien to=Tonga tp=Ost-Timor tr=Türkei tt=Trinidad+Tobago tv=Tuvalu tw=Taiwan tz=Tansania ua=Ukraine ug=Uganda uk=Großbritannien um=US Minor I. us=USA uy=Uruguay uz=Usbekistan va=Vatikan vc=St.Vincent+Gren. ve=Venezuela vg=Virgin I.(britisch) vi=Virgin I.(USA) vn=Vietnam vu=Vanuatu wf=Wallis+Futuna I. ws=West-Samoa ye=Yemen yt=Mayotte yu=Jugoslawien za=Südafrika zm=Sambia zr=Zaire zw=Zimbabwe |
| aero=Airlines arpa=Arpanet biz=Geschäftlich com=Kommerziell |
coop=Kooperation edu=Bildungseinrichtung gov=Regierung info=Info-Dienst |
int=International mil=Militär (US) museum=Museum name=Eigennamen |
nato=NATO net=Provider org=Organisation pro=Professionell |
HTTP (definiert in RFC 1945) benutzt eine ziemlich einfache Syntax. Sie können das mit Windows, Unix oder Linux gelieferte Telnet-Programm benutzen, um nach dem Herstellen einer DFÜ-Netzwerk-Verbindung genau mitzuverfolgen, was passiert. Das ist natürlich nicht so komfortabel wie mit einem Web-Browser, aber man kann den Dialog zwischen Client und Server ganz einfach manuell simulieren. Im folgenden Beispiel sind Ihre Eingaben fett geschrieben; achten Sie bitte genau auf die angegebene Groß- und Kleinschreibung beim Befehl GET und dem dahinterstehenden Dateinamen:
| c:\>telnet www.space.net 80 | Telnet-Start mit Web- Adresse+Portnummer |
| GET /index.htm HTTP/1.0 (und zweimal Enter) | Eine Seite anfordern |
| HTTP/1.0 200 OK Date: Mon, 27 Mar 2007 18:17:14 GMT Server: Apache/1.3.1 Content-type: text/html Content-length: 5921 Last-modified: Fri, 24 Jul 2003 12:15:01 GMT |
Der Server liefert zunächst den HTTP-Header... |
| <html><head>...</head><body>... </body></html> |
...und dann den Seiten-Inhalt. |
| Connection: close | Telnet-Meldung: Verbindung beendet. |
Sie können danach das Telnet-Programm wieder beenden bzw. die Verbindung später erneut aufbauen. (Wenn Sie in der GET-Zeile den Parameter "HTTP/1.0" weglassen, ist das Verhalten undefiniert und von der Server-Software abhängig: Manche Server brauchen hinter GET in diesem Fall nur ein statt zwei Return-Zeichen und liefern dann auch sofort den Inhalt der Seite ohne einen vorangestellten HTTP-Header. Die gezeigte GET-Zeile funktioniert nicht mit jeder Domain, insbesondere nicht mit solchen Webservern, die mehrere Domains unter derselben IP-Adresse verwalten - dafür ist HTTP 1.1 erforderlich, siehe weiter unten.) - Das Beispiel zeigt immerhin bereits ein paar typische Eigenschaften einer HTTP-Verbindung:
Was der Browser mit den auf den Header folgenden Nutzdaten anfangen soll, erkennt er nicht primär an der Datei-Endung wie etwa .htm, .gif oder .jpg, sondern am "Content-type", den man auch oft MIME-Typ nennt. Dadurch kann er sinnvoll reagieren, wenn etwa der Web-Server zum Beispiel eine angeforderte Grafikdatei nicht findet und statt ihrer eine Error-Seite als Text zurückliefert.
Außer GET unterstützt HTTP/1.0 auch den Befehl HEAD; er wirkt wie GET, liefert aber nur den HTTP-Header ohne die Nutzdaten zurück. Damit kann ein Browser feststellen, ob sich die Seite gegenüber dem letzten Abruf geändert hat, und braucht sie ggf. nicht erneut komplett zu laden, sondern kann sie aus der lokalen Cache-Datei holen. Mit PUT kann man schließlich eine Datei zum Server senden, wobei man sich - wenn diese Methode überhaupt freigeschaltet ist - noch mit Benutzername und Passwort identifizieren muss.
Ein Sonderfall ist, wenn die Domain ohne expliziten Dateinamen oder mit einem Unterverzeichnis-Namen ohne Schrägstrich dahinter eingegeben wird, zum Beispiel so:
| c:\>telnet www.space.net 80 | Telnet-Start |
| GET /produkte HTTP/1.0 | "produkte" ist hier ein Verzeichnis. 2 x Enter nicht vergessen! |
| HTTP/1.0 302 Found ... Content-length: 55 Content-type: text/html Location: /produkte/ |
Der Web-Server antwortet nicht mit "OK", sondern mit "Found", und gibt dann mit "Location" auch an, wie man den Inhalt abrufen kann. |
| <HTML><BODY> Directory request redirected. </BODY></HTML> |
Hinterher gibt der Server noch eine Mini-Seite aus, die der Browser aber ignoriert. |
In diesem Fall muss der Browser anhand der Location-Angabe mit "GET /produkte/" das Dokument erneut anfordern. Deshalb wird zum Beispiel die Seite www.altavista.com/ schneller geladen als www.altavista.com ohne Schrägstrich! Neben den oben vorkommenden Status-Codes 200 und 302 gibt es noch eine Reihe anderer. Die wichtigsten sind:
| Code | Text | Bedeutung |
| 200 206 301 302 304 400 401 403 404 405 500 501 503 |
OK Partial content Found, moved permanently Found, moved temporarily Not modified Bad request Unauthorized Forbidden Not found Method not allowed Internal server error Not implemented Service unavailable |
In Ordnung, Befehl wird ausgeführt Wunschgemäß wurde nur ein Teil gesendet Location-Angabe folgt mit neuem Namen Location-Angabe folgt mit neuem Namen Datei seit dem letztem Laden unverändert Falsches Befehlsformat Vorherige Anmeldung mit Passwort nötig Gesperrt, z.B. Directory-Listing bei GET / Nicht gefunden, die Datei existiert nicht Befehlsart nicht erlaubt (HTTP 1.1, s.u.) Server-Fehler z.B. bei fehlerhaftem Script Befehl nicht implementiert Ausführung derzeit nicht möglich |
Der Code 206 (partial content) resultiert aus einem
Request-Header mit einer Angabe wie etwa:
GET /test.htm
bytes=4984 to 9122
Damit fordert der Browser den Server auf, nur einen bestimmten Teil der Datei
zu senden, um beispielsweise nach einem abgebrochenen Download nur den noch
fehlenden Rest zu übertragen.
Der Code 304 (not modified) wird zurückgeliefert, wenn ein Browser beim GET-Befehl im HTTP-Header ein Feld "if-modified-since:" mit Datum und Uhrzeit der in seinem Cache vorhandenen gleichnamigen Datei mitliefert und der Server anhand dieser Angabe feststellt, dass es keine neuere Version davon gibt, so dass es nicht sinnvoll ist, die Datei erneut zu übertragen.
Das ursprüngliche HTTP-Protokoll 1.0 wurde mit HTTP/1.1 (RFC 2068) in einigen Details verbessert und erweitert:
Zur Unterscheidung, welche Protokollvariante benutzt wird, kann man jedem Befehl entweder HTTP/1.0 oder HTTP/1.1 nachstellen. Mit folgender Anforderung kann ein Browser die Startseite der virtuellen Domain petershausen.de vom Shamrock-Server holen (ein Schrägstrich / holt die Startseite, typischerweise index.htm, index.html oder default.html):
| c:\>telnet www.shamrock.de 80 oder: telnet www.petershausen.de 80 |
Start des Telnet-Programms |
| GET / HTTP/1.1 Host: www.petershausen.de HTTP/1.1 200 OK |
Anforderung der Startseite von www.petershausen.de Der Server antwortet dann |
Vergessen Sie bitte nicht, nach der Host:-Zeile zweimal Enter zu drücken, wenn Sie das per Telnet probieren - damit weiß der Server, wo Ihr Anforderungs-Block endet. Ob die Verbindung mit Telnet zu www.shamrock.de oder www.petershausen.de aufgebaut wird, ist zunächst egal, da beide Domain-Namen zur gleichen IP-Adresse und somit zum gleichen Server führen.
Zur Übertragung von sicherheitskritischen Informationen wie etwa Kreditkarten-Daten wird eine zusätzliche Protokollschicht zwischen dem TCP/IP- und dem HTTP-Protokoll eingefügt, nämlich der Secure Socket Layer (SSL). Web-Seiten, die diese Technik benutzen, erkennt man am vorangestellten "https:" statt "http:".
Eine sichere SSL-Verbindung wird von den meisten Browsern mit einem kleinen Vorhänge-Schloss am unteren Fensterrand gekennzeichnet. Dabei ist nicht nur die Verschlüsselung als Sicherheit zu nennen, sondern vor allem auch, dass der Domain-Inhaber bei einer öffentlichen Zertifizierungs-Instanz aufgrund entsprechender Nachweise zeitlich begrenzt (typischerweise jeweils für ein Jahr) als vertrauenswürdig eingestuft wurde. Die Zertifizierung kann betrügerischen Firmen jederzeit wieder entzogen werden. Vor allem deshalb sollte man bei Online-Bestellungen möglichst nur SSL-Seiten benutzen.
Der Client-Browser überprüft die Server-Identität jeweils mit Hilfe dieser Zertifizierungs-Instanz (Certification Authority) und benutzt unterschiedliche Verfahren mit Schlüssel-Längen von 40 bis 168 Bit zur Verschlüsselung der übertragenen Daten:
Das benutzte Public-Key-Verfahren funktioniert so: Der Client-Browser sendet dem Server eine Zufallszahl. Dieser wendet auf die Zahl einen beiden Seiten bekannten Algorithmus an (eine Rechenvorschrift) und sendet das Ergebnis dem Client zurück. Da der Client das richtige Ergebnis kennt, ist damit eine fälschungsssichere Identifizierung des Servers möglich, obwohl der Schlüssel in Form der Zufallszahl quasi öffentlich im Internet übertragen wird.
Wenn Sie einen eigenen Web-Server oder eine Domain bei einem Internet-Provider haben, können Sie anhand der Server-Logs regelmäßig sehen, wie oft welche Seite aufgerufen wurde. Dabei ist allerdings Vorsicht angebracht: In Wirklichkeit könnte die jeweilige Seite wesentlich öfter abgerufen worden sein. Wenn ihr Inhalt nämlich bei einem Cache-Proxy mit Cache zwischengespeichert wurde, erscheint nur ein einziger Proxy-Zugriff im Log, nicht aber die vielen Zugriffe der Benutzer auf den Proxy. Andererseits sagt die Statistik aber auch nichts darüber aus, ob die Besucher die Seite tatsächlich gelesen oder gleich wieder weggeklickt haben.
Viele Internet-Provider bereiten das recht unübersichtliche, umfangreiche Server-Log als Text-Zusammenfassung oder sogar mit Grafiken so auf, dass man auf einen Blick erkennen kann, was am häufigsten abgerufen wurde. Dabei werden einige Begriffe benutzt, die oft auch bei Werbung im Web als Tarif-Grundlage dienen:
Falls im Server-Log auch Verweise von anderen Web-Domains aufgeführt sind (Referrer), können Sie sehen, mit welchen Suchbegriffen Benutzer von Suchmaschinen auf Ihre Seiten gelangt sind. Im folgenden Beispiel hat jemand mit Fireball nach "windows freeware" gesucht; teilweise in einer grafisch aufbereiteten Statistik auch direkt die Suchbegriffe aus solchen Referrer-Zeilen angezeigt:
http://suche.fireball.de/fcgi/query.fcg?action=query&pg=express
&q=+windows+freeware&submit=suchen&what=german_web
Oft erscheint im Server-Log ein Abschnitt mit "umgeleiteten Anfragen" (redirected requests). Wenn beispielsweise jemand einfach nur www.domain.de im Browser eintippt, wird sein Browser auf www.domain.de/ (man beachte den Schrägstrich am Ende) umgeleitet, wie das unter HTTP 1.1 bereits beschrieben wurde. Das ist kein Fehler, sondern völlig normal.
Interessant ist im Log auch die Statistik, welche Browser für das Laden Ihrer Seiten benutzt wurden. Sie können damit besser beurteilen, ob es sich (noch) lohnt, im Seiten-Layout bzw. in Scripts auf ältere oder seltenere Browser Rücksicht zu nehmen.
Zum Thema Datenschutz sei angemerkt: Bei einem Web-Surfer, der sich über einen Internet-Provider einwählt und dem dabei dynamisch eine IP-Adresse zugewiesen wird, enthält das Server-Log keinerlei personalisierte Daten. Es ist nicht möglich, die jeweilige Person zurückzuverfolgen. Man sieht also lediglich, wie oft bestimmte Seiten angesehen und welche Browser benutzt wurden, aber nicht von wem. Lediglich in begründeten Ausnahmefällen kann man den Anrufer vom Provider (z.B. T-Online) anhand von IP-Adresse, Datum und Uhrzeit zurückverfolgen lassen.
Eine Beschreibung der im Internet benutzten Standards wäre unvollständig, wenn dabei nicht erwähnt würde, wie sie zustande kamen. RFC heißt "Request for Comment", zu deutsch "Bitte um Kommentar", und bezeichnet die der Internet-Gemeinde zugeleiteten Standardisierungs-Vorschläge. Diese werden einfach durchnumeriert und tragen Namen wie RFC 1 (das allererste Papier aus dem Jahr 1969 mit dem Titel "Host Software"), RFC 2 und so weiter.
Internet-Pionier Jon Postel war von 1969 bis 1998 RFC-Redakteur; heute kümmert sich eine Gruppe mehrerer Personen im Auftrag der Internet Engineering Task Force IETF darum (siehe http://www.rfc-editor.org). Unter dieser Web-Adresse findet man auch die bisherigen RFC-Dokumente. Alle sind in englischer Sprache verfasst. Nicht alle sind allerdings Definitionen von Standards: Einige haben experimentellen Charakter oder beschreiben allgemeine Zusammenhänge des Internet, zum Beispiel gibt RFC 2505 Tipps zur Vermeidung von unerwünschten Werbe-Mails.
Neben dem im World Wide Web benutzten HTTP-Verfahren definieren RFC-Dokumente auch das Übertragen von E-Mails mit SMTP und POP3 sowie den Dateitransfer mit dem FTP-Protokoll. Diese Themen werden im folgenden Abschnitt behandelt.
Der folgende Abschnitt beschreibt einige weitere typische Internet-Dienste, ohne einen Anspruch auf Vollständigkeit zu erheben; so bleibt etwa das veraltete Gopher-Protokoll unerwähnt. Ein paar praxisnahe Beispiele, die Sie mit dem Telnet-Programm leicht nachvollziehen können, veranschaulichen die Kommunikation etwa beim Mail-Transfer.
| Die Themen dieses Abschnitts: |
E-Mail-Adressen SMTP: Mails senden |
POP3: Mails empfangen FTP: Dateitransfer |
Für E-Mail-Adressen werden Domain-Namen stets ohne die für Web-Server übliche Subdomain "www" benutzt. Eine typische Mail-Adresse zur Web-Seite www.firma.de lautet also z.B. postmaster@example.com. Dabei ist "postmaster" der lokale Benutzername, darauf folgt stets das Zeichen @ (AltGr-Q auf einer deutschen PC-Tastatur) und die Domain.
Bei den meisten Mail-Systemen wird bei Benutzernamen Groß- und Kleinschreibung nicht unterschieden. Statt "postmaster" darf man gewöhnlich also auch "Postmaster" oder "pOsTmAsTeR" schreiben. Dasselbe gilt - wie schon bei Web-Adressen - auch für Domain-Namen.
Mindestens zwei Benutzernamen sollte man für jede Domain einrichten: webmaster (die Person, die die Webseiten der Domain erstellt und pflegt) und postmaster (die Person, die das Mail-System der Domain überwacht). An diese zwei Benutzer sollte man Mails allerdings grundsätzlich nur mit administrativen Fragen senden, Produktanfragen oder gar Werbe-Mails wären hier völlig fehl am Platze.
Um Mails über Ihren Provider ans Internet zu senden, wird seit 1982 das Standard Mail Transfer Protocol (SMTP, RFC 2821) benutzt, das meist über den TCP/IP-Port 25 des Servers erreichbar ist. Wie bei HTTP wird hier wiederum an einem Telnet-Beispiel gezeigt, wie man ganz einfach eine kurze Text-Mail senden kann (Ihre Eingaben sind fett gedruckt):
| c:>telnet smtp.IhrProvider.de 25 220 Sambar SMTP server ready helo example.com250 provider.de Greetings, example.com mail from:<alfred.meier@example.com> 250 sender ok rcpt to:<info@example.com> 250 recipient ok data 354 OK end with <CRLF>.<CRLF> Dies ist eine kurze Beispiel-Nachricht von Alfred Meier an die Firma xyz. . 250 Message accepted for delivery quit 421 Goodbye |
Folgende SMTP-Kommandos werden im obigen Beispiel benutzt:
Die Zahlencodes am Anfang jeder Antwortzeile (im obigen Dialog 220, 250, 354) erleichtern die Auswertung beim automatisierten Dialog eines "echten" Mail-Programms. Die Codes 2xx und 3xx bedeuten "OK", Werte ab 400 melden einen Fehler.
Einige wenige Provider versuchen, die Einlieferung von Massen-Mails (Bulk-Mails, meist unerwünschte Werbe-Mails) zu verhindern, indem sie deren Absendern das Leben mit einer Teergrube (englisch: tar pit) schwer machen. Dabei wird ab dem z.B. fünfzigsten RCPT-Kommando einer Verbindung die Server-Antwort künstlich um acht oder zehn Sekunden verzögert. Das Senden einer Mail an z.B. 10.000 Adressaten (oder auch 100 Mails an je 100 Adressaten) würde so fast einen ganzen Tag dauern. Der Haken dieser Mail-Bremse ist natürlich, dass sie auch anständige Absender betrifft, die beispielsweise Newsletter an Interessenten verschicken, die sich vorher selbst dafür registriert haben.
Die meisten SMTP-Server lassen das Senden von Mails nur zu, wenn man sich vorher eindeutig identifiziert hat, um Spam-, Junk- und Bulk-Mails zu verhindern - so nennt man unerwünschte Werbe-Mails. Das SMTP-Protokoll kennt in seiner ursprünglichen Form keine Authentifizierung mit Benutzername und Passwort; diese wurde später zwar als Option ergänzt (RFC 2554), das Verfahren wird aber nur von wenigen Providern unterstützt.
Meist erfolgt die Identifikation deshalb durch die Einwahl beim gleichen Provider (PPP-Authentifizierung). Nur wer sich beispielsweise bei T-Online einwählt, kann auch den SMTP-Server von T-Online zum Senden von Mails benutzen, andernfalls erhält man die Fehlermeldung "Relaying denied" (Mail-Weiterleitung gesperrt).
Bei Benutzung eines anderen Providers wie z.B. Puretec oder Strato ist oft auch eine vorherige POP3-Identifizierung ausreichend (SMTP after POP3). Leider lassen viele Mail-Programme wie etwa Outlook Express dieses Verfahren aber nur mit umständlichen Tricks zu, da sie normalerweise zuerst alle Mails senden (SMTP) und erst dann anliegende Mails abholen (POP3). Eine der wenigen Ausnahmen ist der NetMail-Server von Shamrock Software: Er sendet sofort nach dem POP3-Login Mails per SMTP und holt parallel dazu Mails via POP3 ab, was zu einer erheblichen Zeitersparnis führt.
Der Text der Nachricht kann als reiner ASCII-Text übertragen werden. Viele Mail-Programme benutzen jedoch den MIME-Standard (Multipurpose Internet Mail Extensions, RFC 1521), der auch Attachments zulässt, z.B. Binärdateien, Grafiken, HTML-Dateien und so weiter. Der Text kann "quoted-printable" codiert sein, so dass auch 8-Bit-Sonderzeichen über 7-Bit-Strecken übertragbar sind. Wenn Sie in Ihrem Mail-Programm mit "Eigenschaften" den Quelltext einer Nachricht ansehen, wird deutlich, wie das funktioniert: Im Mail-Header wird die Art der Codierung beschrieben, und vor hexadezimal codierten Umlauten oder auch vor "weichen" Zeilenumbrüchen steht ein Gleichheitszeichen als Kennung für ein Sonderzeichen, z.B. "=E4" für "ä".
Da Mail-Server eigentlich nur Text übertragen können, werden binäre Dateien üblicherweise im sogenannten Base64-Format übertragen. Dabei werden jeweils 6 Bits aus der Datei als ein ASCII-Zeichen übertragen. Für 6 Bits sind 64 unterschiedliche Zeichen nötig, diese sind:
| 0-25: 26-51: 52-63: |
ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 0123456789+/ |
Aus ursprünglich drei Bytes (24 Bit) entstehen so vier ASCII-Zeichen; die Base64-Codierung bläht die Daten also um 33 % auf. Am Schluss werden ggf. bis zu zwei Zeichen "=" angefügt, um zu erreichen, dass am Dateiende genau 24 Bit zur Decodierung übrig bleiben. Jede Base64-Zeile sollte maximal 76 Zeichen umfassen. Da E-Mails üblicherweise mit dem bereits gesicherten TCP/IP-Protokoll übertragen werden, enthält das Base64-Format keine zusätzliche Prüfsumme. Das untenstehende Javascript-basierte Formular erlaubt das Base64-Codieren und -Decodieren einer Textzeile.
An wen die Nachricht tatsächlich gesendet wird, wird bei SMTP allein durch das RCPT-Kommando bestimmt, nicht durch den Mail-Header, der vom Nutztext durch eine Leerzeile getrennt ist (RFC 2822). Ein Mail-Programm benutzt jedoch gewöhnlich die Angaben in den To-, Cc- und Bcc-Feldern in den Kopfdaten der Mail, um bei der Übertragung entsprechende RCPT-Kommandos zu erzeugen. Die Kopfdaten können unter anderem folgende Felder enthalten, wobei deren Reihenfolge nicht vorgeschrieben ist, und auch Groß- oder Kleinschreibung spielt keine Rolle:
Adressen in den Feldern From, To, Cc oder Bcc benutzen üblicherweise eines der folgenden Formate:
Die Variante 3 wird allerdings nicht empfohlen, auch wenn sie vom Netscape-Messenger (noch) benutzt wird. Angaben in Klammern sind Kommentare (z.B. eine Telefonnummer) und werden beim Mail-Senden ignoriert. Mehrere Mail-Adressen in einer Zeile können durch Kommata voneinander getrennt werden.
Um E-Mails von Ihrem Internet-Provider abzuholen, wird meist das POP3-Protokoll benutzt (Post Office Protocol Version 3, RFC 1725), das gewöhnlich auf dem Port 110 des Servers zur Verfügung steht.
Sie können zu Testzwecken auch hier das Telnet-Programm benutzen, um nachzusehen, ob bei Ihrem POP-Account Mails für Sie bereitliegen, ohne diese unbedingt gleich abholen oder löschen zu müssen. Stellen Sie dazu mit Telnet eine Verbindung zu Port 110 Ihres Providers her und geben Sie die POP-Kommandos manuell ein (Enter-Taste nach jeder Eingabezeile), zum Beispiel so:
| c:>telnet pop.IhrProvider.de 110 +OK Sambar POP3 Server 4.3 ready user IhrName +OK Name accepted pass IhrPasswort +OK Mailbox ready. list +OK message list follows . quit |
Statt list ist auch stat möglich. Falls Nachrichten da sind, können Sie sie nach list mit retr und der zugehörigen Nummer lesen und ggf. mit dele und der Nummer auch löschen, bevor Sie quit eingeben, also etwa so: retr 1 (Nachricht 1 wird geholt), dele 1 (Nachricht 1 wird gelöscht), quit (Verbindung wird beendet). Mit top x y kann man auch nur die ersten y Zeilen der Nachricht mit der Nummer x lesen, um beispielsweise zu prüfen, ob man eine sehr lange Mail wirklich abholen möchte. - Den Dialog, der hier mit dem Telnet-Programm manuell demonstriert wurde, macht ein "richtiges" Mail-Programm wie Outlook-Express, Echange oder Lotus-Notes ganz genauso, nur eben automatisch.
Wenn Sie eine eigene Domain wie IhreFirma.de besitzen, können Sie bei Ihrem Provider dafür gewöhnlich ein POP3-Sammelkonto einrichten, z.B. durch eine Umleitung von *@example.com an info@example.com. Dadurch ist es später möglich, alle E-Mails an Ihre Domain (unabhängig vom Namen vor dem Zeichen @) zeitsparend mit einem einzigen POP3-Anwahlvorgang vom Konto info abzuholen.
Um diese Mails dann z.B. in einem lokalen Netzwerk je nach dem Namen vor @ passend weiterzuverteilen, ist eine Gateway-Software nötig, z.B. fetchmail für Unix/Linux oder, für Windows, NetMail von Shamrock. Sie prüft die hinter To: und Cc: angegebenen Adressen und leitet die Mails dann allen zur lokalen Domain passenden Empfängern zu. Das funktioniert natürlich nicht bei Bcc-adressierten Mails (blind copy), da das Bcc-Feld der Mail schon beim Absender unterdrückt wird und das Weiterleiten im Internet allein durch das SMTP-Kommando "Rcpt to: <Adresse>" erfolgt.
Um bei einer BCC-adressierten Mail, bei der der Empfänger nicht hinter To: oder Cc: steht, trotzdem ermitteln zu können, für wen sie bestimmt ist, fügen einige Server eine zusätzliche Kopfzeile ein, die je nach Mail-System "envelope-to:", "x-envelope-to:", "delivered-to:" oder "x-pop3-rcpt:" heißen kann und die z.B. vom Mail-Programm NetMail auch ausgewertet wird.
Ähnlich fügen einige Mail-Systeme auch eine Zeile "Return-Path:" ein, in der das steht, was der Absender beim SMTP-Kommando "mail from:" übergeben hat. Solche Zusatzangaben, die nicht in den ursprünglich gesendeten Kopfdaten enthalten sind, nennt man auch "mail envelope", zu deutsch Briefumschlag.
Eine Alternative zu POP3 ist IMAP4 (Internet Message Access Protocol Version 4). IMAP4 kann zwar wie POP3 keine Mails senden, besitzt aber zahlreiche Kommandos, um mehrere Unter-Konten (mailboxes) erzeugen und verwalten zu können. Gegenüber POP3 ist es bisher allerdings weniger verbreitet und wird deshalb hier nur am Rande erwähnt.
Das File Transfer Protocol benutzt wie HTTP eine TCP/IP-Verbindung zur Dateiübertragung, beinhaltet jedoch mehr Möglichkeiten, um Verzeichnis-Listings zu übertragen und wird insbesondere oft eingesetzt, um erstellte HTML-Seiten und andere Dateien zu einem Web-Server zu übertragen.
Hierfür gibt es spezielle FTP-Programme, wie etwa das in Windows, Unix und Linux vorhandene FTP-Programm. Wenn Sie es starten, können Sie mit help eine Liste möglicher Befehle anzeigen und es später mit quit wieder beenden. Komfortablere wie das verbreitete WS_FTP bieten zum Teil auch die Möglichkeit, beim Senden großgeschriebene Dateinamen automatisch in die unter Unix üblichen Kleinbuchstaben umzuwandeln. In diesem Zusammenhang sei betont, dass es den meisten Web-Servern keineswegs egal ist, ob man eine Seiten-Adresse mit Web-Browser in Klein- oder Großbuchstaben eingibt: In Unix sind Test.htm und test.htm zwei unterschiedliche Dateien.
FTP-Programme besitzen gewöhnlich einen ASCII- und einen Binärmodus. Im ASCII-Modus wird nur Line-Feed (LF) als Zeilenumbruch-Zeichen übertragen, auch dann, wenn in der Quelldatei jede Zeile CR/LF endet; nur im Binär-Modus (sinnvoll für Grafik-, EXE- und ZIP-Dateien) bleibt die Datei unverändert.
Wer von einem FTP-Server eine Datei herunterlädt, kann das oft ohne vorherige Anmeldung tun und gibt als Pseudo-Benutzername einfach "anonymous" ein. Als Passwort ist es üblich, seine E-Mail-Adresse zu benutzen, aber das ist nicht zwingend erforderlich.
Eine Besonderheit von FTP ist es, dass nicht alles über eine einzige TCP-Verbindung abgewickelt wird: Normalerweise öffnet der FTP-Client einen Steuerkanal zum Host, und der Host-Rechner ruft sozusagen den Client auf einem anderen TCP-Port zurück, der dann für den eigentlichen Datentransfer benutzt wird. Da aber ankommende Verbindungen meist nicht möglich sind, wenn ein Firewall dazwischenliegt, hat man mit dem "passiven Transfer" (PASV) eine Variante geschaffen, bei der Steuer- und Datenkanal vom Client selbst geöffnet werden, so dass es hier nur abgehende Verbindungen gibt.
(Auf ein Telnet-Beispiel zur Demonstration von FTP-Server-Kommandos wie user, pass, port, list, retr, sto, quit usw. wird hier verzichtet, da wegen der Übertragung von Verzeichnislisten und Dateiinhalten über getrennte Ports die Benutzung eines FTP-Servers per Telnet-Programm nicht sinnvoll möglich ist.)
Grundsätzlich kann ein Browser beliebige Dateien von einem Web-Server anfordern - Grafik (typischerweise .jpg oder .gif), ausführbare Programme (Endung .exe in der Windows-Welt) oder komprimierte Dateien (meist .zip). Für typische Web-Seiten mit Hyperlinks (d.h. anklickbaren Text-Teilen und Bildern, die zu anderen Inhalten führen) wird aber nahezu ausschließlich die Hyper-Text Markup Language, kurz HTML, benutzt.
HTML-Seiten kann man als Extremist mit jedem gewöhnlichen Texteditor schreiben, wenngleich das ziemlich mühsam sein kann, insbesondere beim Erstellen von Tabellen. Spezielle WYSIWYG-Editoren (what you see is what you get) wie Microsoft-Frontpage, der in Windows 98 enthaltene kleine Bruder Frontpage Express oder der Netscape-Composer sind deutlich komfortabler, ändern allerdings auch oft den Code nach eigenem Gutdünken.
Es gibt im Internet und auch in Buchform eine ganze Menge Literatur über HTML, so dass hier auf eine ausführliche Auflistung aller HTML-Tags verzichtet wird. Bedenken sollte man auch, dass die Zahl der interpretierten Tags sehr stark vom jeweiligen Browser und seiner Versionsnummer abhängt. Eine besonders empfehlenswerte HTML-Referenz in deutscher Sprache ist Selfhtml von Stefan Münz; sie beinhaltet auch Kapitel über Javascript und Perl.
Eine HTML-Datei kann im einfachsten Fall so aussehen, wobei nur der fett gedruckte Text wirklich im Browser-Fenster angezeigt wird:
| <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <title>Testseite</title> </head> <body> <!-- Beispiel --> <h2>Test</h2> <p><img src="bild.jpg"></p> <hr> <p>Ein Textabsatz<br> mit zwei Zeilen</p> <p><a href="/">Zur Startseite</a></p> </body> </html> |
Deklariert den folgenden Text als HTML Hier beginnt der HTML-Header Die Datei enthält HTML-Text und ist mit dem Zeichencode ISO-8859-1 codiert Erscheint in der Browser-Titelleiste Ende des HTML-Headers Beginn der eigentlichen Nutzdaten So kann man Kommentare einfügen Überschrift der Größe 2 (1=am größten) Ein Absatz mit einem JPG-Bild Eine horizontale Linie wird eingefügt Textabsätze werden automatisch umbro- chen, aber br erzwingt eine neue Zeile Ein Link zur Indexseite der Web-Site Ende der HTML-Nutzdaten Ende der HTML-Datei |
Die meisten HTML-Anweisungen (sog. "tags") werden einmal vor dem betroffenen Textteil verwendet, und dann ein zweites Mal mit einem vorangestellten Schrägstrich hinter ihm, wie etwa <p> und </p>. Nur einige wenige wie <hr> oder <br> kommen einzeln vor. Return-Zeichen (Zeilenumbrüche) im Quelltext werden wie Leerräume behandelt und aufeinanderfolgende Leerräume wie ein einzelner, deshalb muss der Text vollständig und konsequent mit HTML-Tags formatiert werden. (Lediglich Text, den man zwischen <pre> und </pre> einschließt, wird wie eine gewöhnliche ASCII-Datei behandelt, so dass alle Zeilenumbrüche und Mehrfach-Leerräume erhalten bleiben.)
Da die Zeichen < und > für HTML-Anweisungen benutzt werden, dürfen sie im normalen Text so nicht vorkommen. Sie werden deshalb als sog. Entities codiert, nämlich als < (less than) und > (greater than). Wenn Sie in diesem Text etwa "<p>" lesen, steht in der Datei in Wirklichkeit "<p>". Dadurch muss natürlich auch das Ampersand-Zeichen & umcodiert werden; es wird in der HTML-Datei zu "&". Manchmal werden auch deutsche Umlaute umcodiert, etwa "ä" zu "ä", aber eigentlich war das nur bei den früheren 7-Bit-Übertragungsstrecken wirklich nötig. Wenn man im HTML-Header den Zeichensatz eindeutig angibt (z.B. ISO 8859-15), darf man Umlaute unverändert in den Text schreiben.
Das Euro-Zeichen ¤ weist eine besondere Problematik auf. Im Zeichencode ISO-8859-1 existiert es streng genommen nicht; Dokumente, die es verwenden, müssen entweder in ISO-8849-15 oder in UTF-8 codiert sein. Allerdings fügen in beiden Varianten viele Quelltext-Editoren den Windows-Zeichencode für ¤ ein, der im Browser dann falsch erscheint. Umgekehrt erscheint ein im Browser mit ISO-8859-15 korrekt angezeigtes Euro-Symbol im Quelltext-Editor oft fälschlich als Währungssymbol ¤ und kann dort auch so zum Einfügen des Euro-Symboles verwendet werden.
Standardisierungsbemühungen führten dazu, dass es heute zum guten Ton gehört, noch vor das einleitende <html> einer Webseite eine Typdeklaration zu schreiben, damit ein Browser weiß, nach welchen Regeln er den HTML-Code zu decodieren hat. Falls ganz auf Style Sheets und Frames verzichtet wird, kann das Dokument als HTML-3.2-konform deklarieren (veraltet!):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
Im Normalfall wird man aber HTML 4.01 verwenden:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
Dabei steht EN für eine englischsprachige Typdefinition (trifft bei HTML immer zu; es ist nicht die Dokument-Sprache gemeint!). DOCTYPE muss immer groß geschrieben werden! Wie "Transitional" und "loose" schon suggerieren, ist diese Variante noch relativ großzügig hinsichtlich der Kompatibilität mit älteren Browsern und erlaubt sowohl ältere Elemente wie FONT, ALIGN, FRAME und IFRAME (was bei "strict" nicht mhr erlaubt ist, siehe unten) als auch gegenüber HTML 3.2 neuere wie etwa Style Sheets (CSS). Außer dem Typ selbst ist auch angegeben, wo im Web die Typdefinition zu finden ist. Wenn man auf diese Angabe verzichtet, sieht es so aus:
<!DOCTYPE
HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Die Folge davon ist, dass (ähnlich wie beim vollständigen Fehlen des DOCTYPE) die gängigen Browser dann den sogenannten Quirks-Modus benutzen, der absichtlich eine Reihe von Darstellungsfehlern früherer Browser-Generationen simuliert. Dazu gehört beispielsweise, dass in Tabellen die Formatangaben des HTML-Body nicht übernommen werden (z.B. Zentrierung und Schriftgröße) oder dass hinter Pixelangaben in Stylesheets kein "px" nötig ist.
Für Framesets wird folgende Variante verwendet (das Wort Transitional ist hier überflüssig, da es bei der Strict-Variante ohnehin keine Frames gibt):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
Wer keine HTML-Elemente wie FONT, ALIGN, CENTER, FRAME und IFRAME mehr benutzt, auf das Link-Attribut TARGET verzichtet und und zur Formatierung voll auf Style Sheets setzt, kann die "Strict"-Variante verwenden:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
Tabellen sind ein häufig verwendetes Element zur Gestaltung einer Webseite, auch als blinde Tabellen (d.h. ohne sichtbare Rahmen) zur Positionierung von Text, Bildern und Eingabefeldern. Die Dicke des Außenrahmens wird im table-Tag mit border angegeben, die der Gitterlinien mit cellspacing und der Textabstand zum Zellenrand mit cellpadding.
| <table border="2" cellpadding="4" cellspacing="6"
bgcolor="red"> <tr><td>1</td><td>2</td><td>3</td></tr> <tr><td>4</td><td>5</td><td>6</td></tr> </table> |
Tabellenbeginn 1. Zeile, 3 Spalten 2. Zeile, 3 Spalten Tabellenende |
||||||
| Und so sieht diese Tabelle dann im Browser aus: |
|
Übrigens ist es guter Stil (und bei XML/WML sogar zwingend erforderlich), Werte hinter HTML-Tags immer in Anführungszeichen zu schreiben, in diesem Beispiel also etwa border="2" statt border=2. - Zur Positionierung von Elementen stehen alternativ auch CSS-Methoden zur Verfügung.
Als Formular, englisch Form, bezeichnet man einen Bereich innerhalb einer HTML-Datei, der ausfüllbare Felder enthält. Diese können dann beispielsweise mit einem Javascript-Programm vom Browser auf Plausibilität überprüft werden, bevor sie mit einem Absende-Button zum Server geschickt und dort z.B. mit einem Perl-CGl-Programm ausgewertet werden. Jede Form beginnt mit <form> und endet mit </form>, und dazwischen können unterschiedliche Feldtypen stehen. Mit name wie z.B. in <input type="text" name="Mail"> kann man den Feldern für die spätere Unterscheidung im CGI-Programm Namen geben.
Bei einem mit <form method="get" action="http://..."> eingeleiteten
Formular übergibt der Browser die Feldnamen und -inhalte einem CGI-Programm
durch Anhängen der Daten an den Programmnamen hinter einem Fragezeichen, und
zwischen den einzelnen Feldern wird das Trennzeichen & eingefügt. Einige
reservierte Zeichen werden dabei hexadezimal codiert, z.B. & als %26, + als %2B
oder % als %25, und Leerzeichen werden als "+" übergeben. Ein Beispiel mit zwei
Feldern:
/cgi-bin/mail.pl?Mail=info@example.com&Name=Meier+%26+Huber
Mit method="post" werden die Daten dem CGI-Programm dagegen über das
STDIN-Handle übergeben; diese Methode ist insbesondere für längere Daten wie
etwa mehrzeilige Texte besser geeignet.
Bei einem Textfeld kann man mit <textarea wrap="hard"> erzwingen, dass Zeilenumbrüche genau so übertragen werden, wie sie bei der Eingabe sichtbar sind. Mit <textarea wrap="soft"> werden sie dagegen nur dort übertragen, wo man wirklich die Enter-Taste gedrückt hat. Das dafür benutzte wrap-Attribut ist im HTML-Standard zwar nicht vorgesehen, wird aber von fast allen Browsern verstanden und häufig benutzt, da es bisher keine Alternative dafür gibt.
Nur der Vollständigkeit halber sei die Möglichkeit erwähnt, mit <form action="mailto: ..."> ein Formular mit Hilfe des Mail-Programms des Benutzers als E-Mail zu versenden. Dies funktioniert nur dann, wenn Browser und Mail-Programm eine monolithische Einheit bilden (z.B. MS-IE und Outlook, oder Netscape-Browser und -Messenger). Da viele Benutzer mit anderen Kombinationen arbeiten, ist diese Lösung viel zu unzuverlässig und deshalb zumindest für kommerzielle Aufgaben völlig unbrauchbar.
Man kann den Browser-Bildschirm in mehrere Teilfester unterteilen, in denen unterschiedliche Dokumente bzw. Dateien dargestellt werden. Beispiel:
| <html> <head><title>Frames-Testseite</title></head> <frameset cols="250,*" frameborder="0" framespacing="0" border="0"> <frame src="file1.htm"> <frame src="file2.htm"> </frameset> <body> Dieser Text erscheint nur bei einem nicht framefähigen Browser! </body></html> |
Die Angabe cols="250,*" bedeutet hier, dass eine spaltenweise Frame-Darstellung gewünscht wird; der linke Teil mit der Datei file1.htm soll immer genau 250 Pixel breit sein, und der rechte mit file2.htm nimmt den Rest der Bildschirmbreite ein. Der Abstand zwischen den Frame-Teilen wird auf Null gesetzt.
Ein innerhalb eines Frame-Teils stehender Link zu einer fremden Seite muss
z.B. so aussehen:
<a href="http://www.xyz.de/" target="_top">
Ohne "_top" würde die fremde Seite innerhalb Ihres Frames erscheinen und so den
falschen Eindruck erwecken, zu Ihrem Angebot zu gehören - das Urheberrecht
verbietet das.
Auf ein kleines Problem bei Frames sei hingewiesen: Suchmaschinen indizieren meist alle Seiten, also auch die Teilseiten einer Frame-Struktur. Wenn man keine besonderen Tricks anwendet (z.B. Nachladen der Frames mit Javascript), wird der Besucher der Seite deren Schönheit nur teilweise genießen können.
Insbesondere für das Zusammenspiel mit Suchmaschinen sind einige Angaben im HTML-Header von Bedeutung. Ein entsprechend optimierter Header sollte zumindest Angaben wie Title, Description und Keywords beinhalten, die ein normaler Browser zwar ignoriert (daher der Name Meta-Tags), die aber von den meisten Suchmaschinen ausgewertet werden. Ein kleines Beispiel einer HTML-Datei mit Meta-Tags:
| <html><head> <title>Relativitätstheorie</title> <meta http-equiv="Language" content="de"> <meta name="Description" content="Die ganze Theorie in einem Satz"> <meta name="Keywords" content="Geschwindigkeit,Masse,Licht"> <meta name="Author" content="A. Einstein, L. Infeld"> <meta name="Copyright" content="Albert Einstein"></head> <body><p>Wer rast, wird schwerer und kürzer, und niemand schafft mehr als 300.000 km/s.</p></body></html> |
Die Angabe "de" bei "Language" hilft internationalen Suchmaschinen bei der Einordnung der Seite zur passenden Landessprache. Der Titel hinter <title> sollte unbedingt da sein. Wenn "Description" fehlt, nimmt die Suchmaschine als Kurzbeschreibung die ersten Worte im Text, was meist nicht besonders aussagekräftig ist. Meist werden bei der Suchmaschinen-Ausgabe auch Autor und Copyright angezeigt, deshalb sollten diese Angaben nicht fehlen. Die "Keywords" dienen in erster Linie dazu, Synonyme von Begriffen anzugeben, die zum Thema gehören, aber so im übrigen Text möglicherweise nicht vorkommen. (Groß- und Kleinschreibung ist bei den Meta-Tag-Namen egal.)
In manchen Fällen möchte man, dass eine Suchmaschine eine bestimmte Seite
nicht in ihren Index aufnimmt. Dazu kann man in den HTML-Header folgende Zeile
schreiben:
<meta name="robots" content="noindex,nofollow">
Dabei bedeutet noindex, dass die Suchmaschine diese Seite nicht indizieren
soll, und nofollow, dass sie auch keinen Links folgen soll, die auf dieser
Seite stehen.
Außer Meta-Tags haben allerdings auch andere Parameter wesentlichen Einfluss darauf, ob ein Besucher Ihre Seite über eine Suchmaschine findet bzw. an wievielter Stelle Ihre Seite beim Suchen nach bestimmten Begriffen erscheint (Ranking). Da Suchmaschinen mit unterschiedlichen Bewertungskriterien arbeiten, haben natürlich nicht alle Maßnahmen bei allen Maschinen dieselbe Wirkung. Dennoch ein paar Tipps hierzu:
Dienste, bei denen man eine Seite kostenlos oder gegen Gebühr bei hunderten Suchmaschinen anmelden kann, sind oft völlig ineffizient, und eine Erfolgskontrolle ist nahezu unmöglich. Da in der Praxis einige wenige Suchmaschinen einen Großteil des Verkehrs bringen, ist eine manuelle Einzel-Anmeldung nicht allzu aufwendig: Allein Google bringt nach der Statistik des Shamrock-Servers mehr als die Hälfte der referenzierten Seiten, alle anderen Suchmaschinen liegen einzeln jeweils unter fünf Prozent (Stand September 2002).
Bis eine Seite nach der Anmeldung tatsächlich im Index erscheint, dauert bei den einzelnen Suchmaschinen sehr unterschiedlich lang - von ein bis zwei Tagen (Fireball) über ein paar Wochen (Google) bis zu einigen Monaten (Yahoo). Eine Neuindizierung geänderter Seiten erfolgt durch die Suchmaschinen in der Regel automatisch im Abstand einiger Wochen oder Monate.
Man kann Schriftart-Anweisungen überall im HTML-Text unterbringen, z.B. so:
<b> oder <strong>: Der folgende Text ist fett (Ende mit </b>
oder </strong>)
<i> oder <em>: Der folgende Text ist kursiv (Ende mit </i> oder </em>
<font color="red">: Der folgende Text ist rot
(Ende mit </font>)
<font size="-1">Der folgende Text ist eine Stufe kleiner
(Ende mit </font>)
Wenn man bestimmte Schriftarten und sonstige stilistische Eigenheiten auf einer Web-Site immer wieder benutzen möchte, kann die immer wiederkehrende Definition allerdings recht aufwendig werden. Deshalb gibt es sogenannte Cascading Style Sheets (CSS). Man kann sie auf unterschiedliche Arten benutzen:
Außer für die vorgegebenen HTML-Elemente wie etwa p (Textabsatz), h1...h6
(Überschriften) oder td (Tabellenzelle) kann man auch einen eigenen Namen
definieren, z.B. "bg" für einen Textteil mit Hintergrundfarbe. Dazu schreibt
man in den HTML-Header:
<style type="text/css"><!--
.bg { background:#FFF8C8; }
--></style>
Im HTML-Body, also im eigentlichen Seitentext, kann man den Stil dann wie
folgt einsetzen:
Dies ist ein Text mit <span class="bg">Hintergrundfarbe</span>.
Style Sheets werden von Microsoft- und Netscape-Browsern seit Version 4.0 unterstützt. Da frühere Versionen kaum noch im Einsatz sind, kann man dieses Formatierungs-Verfahren guten Gewissens einsetzen.
Außer mit Meta-Tags kann man auch mit einer Datei robots.txt im Hauptverzeichnis des Servers verhindern, dass Suchmaschinen bestimmte Dateien und Verzeichnisse indizieren. Die folgende Beispieldatei vermeidet, dass Suchmaschinen Dateien im Verzeichnis cgi-bin indizieren:
| # Beispiel für robots.txt User-agent: * Disallow: /cgi-bin/ |
Dabei bedeutet die Zeile "User-agent: *", dass das für alle Suchmaschinen gelten soll. Wenn mehrere Verzeichnisse oder Dateien gesperrt werden sollen, kann man mehrere Disallow-Zeilen angeben. Hinter der Raute # dürfen Kommentare stehen.
Der Microsoft Internet Explorer ab Version 5.0 sucht im aktuellen Verzeichnis des Web-Servers nach einer Datei favicon.ico, wenn Sie eine Seite in die Favoriten-Liste aufnehmen. Dabei handelt es sich um eine Grafikdatei in dem bei Windows-Applikationen üblichen Icon-Format, die der Explorer sich in der versteckten Datei ShellIconCache merkt. Um sie zu erstellen, benötigt man einen Icon-Editor, wie er auch bei den meisten Entwicklungs-Umgebungen für Windows enthalten ist.
Wenn keine solche Datei auf dem Web-Server existiert, wird man im Server-Log regelmäßig den Fehler 404 (Datei nicht vorhanden) bemerken, wenn jemand versucht, mit dem MS-IE ab 5.0 eine Seite in die Favoriten aufzunehmen. Das klappt zwar trotzdem, aber natürlich erscheint in der Favoriten-Liste dann keine Grafik.
Apache- und dazu kompatible Web-Server erlauben das Erstellen einer Datei .htaccess mit speziellen Server-Optionen (bitte beachten Sie den führenden Punkt und die Kleinschreibung!). Die Angaben in .htaccess wirken auf das Server-Verzeichnis, in dem sich diese Datei selbst befindet, sowie auf alle darunterliegenden. Die Datei .htaccess muss im ASCII-Modus (nicht binär) per FTP zum Server übertragen werden.
Eine typische Verwendungsmöglichkeit ist die Angabe einer Error-Seite, die bei bestimmten Server-Fehlercodes aufgerufen werden soll. Wenn Sie beispielsweise möchten, dass beim Fehler 404 (not found) das Dokument error404.htm angezeigt wird und beim Fehler 401 (unauthorized) die Seite error401.htm, erstellen Sie eine Datei .htaccess mit folgender Zeile:
ErrorDocument 404 /error404.htm
ErrorDocument 401 /error401.htm
Es ist wichtig, in den Kopfdaten der Error-Dateien mit <meta name="robots" content="noindex"> zu verhindern, dass Suchmaschinen die fehlerhafte Adressen indizieren.
Eine weitere Möglichkeit ist das Schützen von Unterverzeichnissen, so dass diese nur nach Eingabe von Benutzername und Passwort zugänglich sind. Dazu muss im jeweiligen Unterverzeichnis (z.B. "privat") eine Datei .htaccess mit folgendem Inhalt angelegt werden:
AuthType Basic
AuthName "Restricted Directory"
AuthUserFile /homepages/htdocs/privat/.htpasswd
require valid-user
Zusätzlich ist dafür eine Datei .htpasswd im selben Verzeichnis nötig, die einen oder mehrere Benutzernamen und zugehörige Passworte enthält. Ihr Pfad wird in .htaccess als absoluter Server-Pfad angegeben. Die Passworte sind dabei verschlüsselt. Beispiel für .htpasswd:
schmitz:kw8U4x3
Sie können den Code für ein Passwort mit dem folgenden Formular ermitteln. Da der Algorithmus einen Zufallswert als Ausgangsbasis für die Verschlüsselung benutzt, sind für ein Passwort unterschiedliche Codes für .htpasswd möglich.
Bitte achten Sie beim Transfer von .htaccess und .htpasswd zu einem Unix-Webserver darauf, dass Sie im FTP-Programm den ASCII-, nicht den Binär-Modus benutzen, da andernfalls ein Server-Error gemeldet wird. Bei manchen Internet-Providern ist das Hochladen einer Datei .htaccess allerdings gesperrt.
Mit einer einfachen Umleitung kann eine beliebige andere Datei aufgerufen werden, wenn im Browser eine (typischerweise nicht wirklich existente) Datei angefordert wird. Im folgenden Beispiel wird bei Auruf des Dateinamens datei.htm in Wirklichkeit ein CGI-Skript prog.pl gestartet, ohne dass das in der Adressenzeile des Browsers sichtbar wird. Das Zeichen ^ wird hier zur Kennzeichnung des Anfangs und $ für das Ende der angeforderten URL benutzt; ggf. könnten auch mehrere RewriteRule-Zeilen für weitere Umleitungen angegeben werden:
RewriteEngine on
RewriteRule ^datei.htm$ /cgi-bin/prog.pl
Oft ist es unerwünscht, dass Download-Dateien oder Bilder von fremden Servern "gelinkt" werden. Um das zu verhindern, kann man eine Datei .htaccess mit folgendem Inhalt in das entsprechende Unterverzeichnis kopieren:
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://IhreFirma.de.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.IhreFirma.de.*$ [NC]
RewriteRule /* http://www.IhreFirma.de/error.htm [R,L]
Voraussetzung ist natürlich, dass sich alle vor fremden Links zu schützenden Dateien zusammen mit .htaccess in einem eigenen Unterverzeichnis befinden, da sonst auch externe Links zu Ihren normalen HTML-Seiten nicht mehr möglich wären. Im obigen Beispiel sind Downloads nur als Links von den Domains IhreFirma.de und www.IhreFirma.de erlaubt. Bei fremden Links erfolgt mit "RewriteRule" eine Umleitung zur Seite error.htm des Servers IhreFirma.de. (Diese Seite sollte im Header mit <meta name="robots" content="noindex"> verhindern, dass sie von Suchmaschinen indiziert wird.)
Die erste ReWriteCond-Anweisung sorgt dafür, dass es keine Probleme gibt, wenn der Browser oder Proxy die Adresse der vorherigen Seite (Referer) nicht meldet. Die Angabe [NC] bedeutet "No Case", Groß- und Kleinschreibung wird also ignoriert. Das R in [R,L] bedeutet Redirection (Umleitung), das L beendet die Umleitungs-Regeln.
Mit der folgenden .htaccess-Datei ist es möglich, bekannte Spambots auszusperren; das sind Suchroboter, die Webseiten nach E-Mail-Adressen durchsuchen, um dann Werbe-Mails zu versenden. Ferner wird das Saugprogramm Wget ausgesperrt, das ganze Websites anhand der enthaltenen Links ausliest. In beiden Fällen liefert der Webserver dann den Status 403 = Forbidden zurück.
ErrorDocument 403 /error403.htm
ErrorDocument 404 /error404.htm
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} (Email|Crescent|^wget|^$) [NC]
RewriteRule !error - [F]
Die ersten beiden Zeilen definieren für die Fehler 403 (forbidden) und 404 (file not found) zwei passende HTML-Dateien, die dann angezeigt werden. Die folgenden Zeilen sorgen dafür, dass Browser bzw. Robots, in deren Identifikation irgendwo die Worte Email oder Crescent vorkommen, deren Identifikation mit wget beginnt (^=String-Anfang) oder die sich überhaupt nicht identifizieren (^$ = Leerstring), den Status Forbidden erhalten, der zur Anzeige der Datei error403.htm führt. Damit diese Fehlerdatei selbst aber angezeigt werden kann, werden Dateien, die die Zeichenfolge "error" enthalten, vom Forbidden-Status ausgenommen.
Unternehmen, die Kreditkarten-Zahlungen auf Webseiten akzeptieren, sind zur Einhaltung von Mindeststandards bei der Verschlüsselung der Bestellseite und des zugehörigen Formular-Scripts verpflichtet. Mit der folgenden Zeile in .htaccess wird die veraltete SSL-Version 2 mit dem Fehlercode 403 = Forbidden abgelehnt, und es werden nur SSL-Verbindungen mit mindestens 128 Bit Schlüssellänge akzeptiert:
SSLRequire %{SSL_PROTOCOL}!="SSLv2" && %{SSL_CIPHER_USEKEYSIZE}>=128
Selbstverständlich muss aber auch die gesamte weitere Bearbeitung der Kreditkartendaten gesichert erfolgen. - Erwähnenswert ist, dass die beiden hier verwendeten SSL-Environment-Variablen zwar in .htaccess, nicht aber in einem CGI-Script zur Verfügung stehen.
Außer Text können Web-Seiten auch Bilder, Download-Dateien und Multimedia-Elemente enthalten. Im Web-Server wird bestimmten Dateiendungen jeweils ein MIME-Inhaltstyp zugewiesen (Multipurpose Internet Mail Extensions), der im HTTP-Header übertragen wird, so dass der Browser weiß, was er mit den folgenden Daten anfangen soll, selbst dann, wenn er die Dateiendung selbst nicht kennt. Die folgende Übersicht nennt ein paar häufige Dateitypen, ohne einen Anspruch auf Vollständigkeit zu erheben.
| Endung | MIME-Typ | Kompression | Verwendung |
| asp avi cdf gif htm, html ico jpe, jpg, jpeg js m3u, mp3url mid mov, qt mp3 mpe,mpeg,mpg png ra ram, rm shtml, shtm, sht swf txt viv, vivo wav wml htm, xml o.ä. zip Sonstige |
application/x-asap video/x-msvideo application/x-netcdf image/gif text/html image/ico image/jpeg application/x-javascript audio/x-mpegurl audio/x-midi video/quicktime audio/x-mpeg video/mpeg image/png audio/x-realaudio audio/x-pn-realaudio text/html application/x-shockwave-flash text/plain video/vivo audio/x-wav text/vnd.wap.wml xml+xhtml application/x-zip-compressed application/octet-stream |
keine verlustbehaftet keine verlustfrei keine keine verlustbehaftet keine keine keine verlustbehaftet verlustbehaftet verlustbehaftet verlustfrei verlustbehaftet verlustbehaftet keine keine keine verlustbehaftet keine keine keine verlustfrei je nach Typ |
Active Server Pages Videosequenzen Channel Definition File Bilder bis 256 Farben HTML-Text Grafik-Icon Bilder (typ. Fotos) Javascript-Dateien Link-Datei zu MP3-File Synthesizer-Musik Apple-Quicktime-Video Audio (typ. Musik) Videosequenzen Weiterentwickl.von GIF Echtzeit-Audio Echtzeit-Video/Audio HTML mit SSI Shockwave-Flash Reiner ASCII-Text Vivo-Video Wave-Audio WAP1-WML-Seiten WAP2-XHTML-Seiten Download-Dateien Beliebige andere |
Die Spalte "Kompression" gibt an, ob die Information in den Dateien in komprimierter Form vorliegt, und ob die Kompression verlustbehaftet ist oder nicht. Verlustbehaftete Verfahren wie JPG oder MP3 nehmen im Interesse einer geringeren Dateigröße bewusst in Kauf, dass die ursprüngliche Information nicht in der vollen Qualität des Originals wiedergewonnen kann, und nutzen dabei Schwächen der menschlichen Sinnesorgane aus. Bei Bildern sind folgende Formate üblich:
Damit sich Seitenteile nicht während des Ladens von Bildern dauernd verschieben, ist es sinnvoll, die Bildgröße mit anzugeben (Attribute width und height im img-Tag). Beispiel:
<a href="neu.htm"><img src="pic/neu.gif" alt="Neu!" border="0" width="40" height="30"></a>
Der Browser kann dann auf der Seite von vornherein den nötigen Platz für das Bild reservieren. Ferner kann man mit alt="..." einen Text angeben, der nicht nur angezeigt wird, wenn das Bild aus irgend einem Grund nicht geladen wird, sondern auch auch beim Überfahren des Bildes mit der Maus. Die Angabe border="0" verhindert einen Rahmen um das Bild, wenn es gleichzeitig als Link dient.
Wer
im Web surft, stößt immer wieder auf Seiten, die nicht korrekt angezeigt
werden, die unglaublich langsam sind, bei denen Links nicht funktionieren oder
die Script-Fehlermeldungen produzieren. Damit Sie selbst solche Fehler
vermeiden, hier ein paar Web-Design-Tipps.
Es ist natürlich zeitaufwendig, alle Seiten manuell auf fehlerhafte Links, falsche Pfadangaben, DOS-Umlaute und ähnliche Probleme zu überprüfen. Ein Tool wie die Freeware TopSite von Shamrock Software findet solche typischen Fehler per Knopfdruck.
Mit Seiten, die spezielle Plugins erfordern, sollte man sehr sparsam umgehen. Ein Beispiel dafür ist Flash von Macromedia, das animierte Grafiken und Texte erlaubt. Die Nachteile dieser Technologie gegenüber echtem HTML:
Deshalb sollte Flash bestenfalls auf Unterseiten eingesetzt werden, bei denen eine Animation zur Verdeutlichung von Inhalten erforderlich ist, aber keinesfalls zur Navigation auf der Homepage.
Das Behindertengleichstellungsgesetz vom 27. April 2002 (BGBl. I S. 1467) fordert in § 11 Abs. 1, dass die Webseiten deutscher Behörden auch für Behinderte (zum Beispiel Blinde) uneingeschränkt zugänglich, also barrierefrei sein müssen. § 11 Abs. 2 sieht ausdrücklich vor, dass das zumindest auf freiwilliger Basis auch für andere, nicht von Behörden erstellte Webseiten gelten sollte.
Die Verordnung hat nicht das Ziel, Sonderlösungen (z.B. Spezialseiten) für Behinderte zu fordern, sondern die für nicht behinderte Menschen konzipierten Webseiten so zu verbessern, dass auch Behinderte damit klarkommen. Bedenken Sie, dass Behinderte sich in ihren kognitiven und mechanischen Fähigkeiten stark von anderen Menschen unterscheiden:
Bei Computern mit Sprachausgabe wird der Text einer Seite stückweise ausgegeben. Springt man z.B. mit der Tab-Taste von einem Link zum nächsten, wird der Link-Text gesprochen, und man kann mit der Enter-Taste zum Link-Ziel springen. Bei Bildern wird der ALT-Text als Sprache ausgegeben. Javascript-Navigationselemente können meist nicht benutzt werden.
Daraus resultiert eine Reihe von Anforderungen an Webseiten, die teilweise bereits auch bei den Design-Tipps erwähnt wurden, weil sie keineswegs nur für Behinderte sinnvoll sind. Die wichtigsten sind:
Generell lässt sich sagen: Je stolzer ein Web-Designer auf seine glanzvolle Programmier- und Gestaltungs-Leistung ist, desto ungeeigneter ist die Seite für Behinderte. Nach wie vor sind die Seiten selbst großer Firmen für Sehbehinderte und Blinde, die z.B. als Kunden sehr wohl zur Zielgruppe gehören, völlig unbrauchbar.
Firmen müssen bei ihrem Web-Auftritt laut dem deutschen Telemediengesetz (TMG, früher Teledienstegesetz = TDG) mindestens folgende Angaben bereitstellen:
Die Formulierung "...einschließlich der Adresse der elektronischen Post" bedeutet übrigens nicht zwangsweise, dass man einen von Spam-Robots (Spambots) auffindbaren mailto:-Link benötigt, der dann dazu führt, dass man mit unerwünschten Werbe-Mails überschüttet wird. Zu einer Mail-Adresse im Klartext gibt es einige Alternativen:
Nach einer Entscheidung des Landgerichts Essen vom 19.09.2007 (Az. 44 O 79/07) ist ein Kontaktformular als Ersatz für eine Mail-Adresse nicht ausreichend.
In HTML-Seiten kann man kleine Programme einbetten, die in Javascript (von Netscape eingeführt) bzw. dem dazu halbwegs kompatiblen JScript (Microsoft) geschrieben sind. Eine weitere Alternative ist das allerdings nur von Microsoft-Browsern unterstützte VBScript, das an Visual Basic angelehnt ist.
Man kann solche Programme so in HTML einbetten, dass der Browser (der Client) das eingebettete Programm interpretiert und beispielsweise dynamisch neue Fenster öffnet oder Eingaben überprüft. Alternativ kann auch der Web-Server selbst Programmstücke in HTML-Seiten interpretieren. Bei Microsoft nennt man solche Seiten ASP (Active Server Pages). Ferner wird auf Web-Servern oft die Script-Sprache Perl eingesetzt, beispielsweise zur Verarbeitung von Formular-Eingaben oder, wie bei ASP oder PHP, zur Generierung dynamischer Seiteninhalte. Server-Side Includes (SSI) sind eine weitere einfache Möglichkeit zur dynamischen Seitengestaltung.
| Die Themen dieses Abschnitts: | Javascript VBScript HTA-Dateien Perl und CGI |
Server-Side Includes PHP Cookies Sicherheitslücken |
Javascript ist die derzeit am häufigsten eingesetzte client-seitige Programmiersprache. Das folgende Beispiel ist in dieser Sprache geschrieben und erzeugt beim Anklicken von diesem Link einfach ein kleines Fenster mit dem Text "Hallo Welt!".
| <html><head><title>Test</title> </head><body> |
Der übliche Beginn einer HTML-Datei. |
| <script language="JavaScript"><!-- function fenster() { alert("Hallo Welt!"); } // --><script> |
Eine kleine Javascipt- Funktion, die eine Message- Box mit OK-Knopf öffnet. |
| <noscript><p> Sie haben Javascipt ausgeschaltet! </p></noscript> |
Dieser Text wird angezeigt, wenn der Benutzer Java- script deaktiviert hat. |
| <p><a href="javascript:fenster()"> Bitte hier klicken!</a><p> |
Ein Text als Link, der die Fenster-Funktion aufruft. |
| </body></html> | Das übliche HTML-Ende. |
Das kleine Javascript-Programm ist für ältere Browser, die noch keine Script-Sprachen verstehen, in Kommentar-Anweisungen zwischen <!-- und --> eingebaut, so dass sie keinen Unsinn anzeigen. Da sie auch die Anweisung <noscript> nicht verstehen, wird von Ihnen der zwischen <noscript> und </noscript> stehende Text angezeigt. Dasselbe passiert, wenn man in einem modernen Browser Javascript abschaltet.
Die zwei Schrägstriche (//) am Beginn der ersten Zeile nach dem Javascript-Code sorgen dafür, dass diese Zeile vom Script-Interpreter als Javascript-Kommentar aufgefasst wird, so dass er nicht auf die Idee kommt, das darauffolgende HTML-Tag "-->", das den HTML-Kommentar beendet, zu interpretieren, was zu einer Fehlermeldung führen würde.
Der Code wird in der HTML-Datei genau an der Stelle ausgeführt, an der er steht, und natürlich auch zu dem Zeitpunkt, zu dem der entsprechende Teil der HTML-Datei geladen wird. Deshalb muss ein Javascript-Programm, das auf weiter hinten stehende HTML-Elemente der Seite bezug nimmt, etwa auf Anker (lokale Link-Ziele innerhalb der Datei) oder Formular-Felder, entweder am Ende der Datei stehen oder als Funktion mit <body onload="funktion( )"> im body-Tag der HTML-Seite erst dann aufgerufen werden, wenn die Seite vollständig geladen ist.
Es kann beliebig viele Javascript-Abschnitte in einer HTML-Datei geben. Man kann auch mitten in der Seite einen per Javascript generierten Text einfügen, z.B. so:
| <p><script language="Javascript"><!-- document.write("Letzte Änderung: ",document.lastModified); // --></script></p> |
Eine nützliche Anwendung von Javascript ist auch das automatische Nachladen von Frames, wenn ein Benutzer z.B. von einer Suchmaschine kommend nur eine einzelne Datei des Framesets aufruft und ihm dadurch die im Frameset vorhandenen Navigations-Möglichkeiten zunächst fehlen. In jeder Teildatei braucht dazu nur folgendes enthalten zu sein, wobei frame.htm in diesem Beispiel die Frameset-Definition enthält:
| <script language="JavaScript"><!-- if (parent.frames.length<1) location.replace("frame.htm"); // --></script> |
Der Javascript-Code braucht nicht unbedingt in der HTML-Datei selbst
enthalten zu sein. Es ist auch möglich, ihn in einer getrennten Datei
zu speichern, typischerweise mit der Endung .js, und in den HTML-Code folgende
Zeile einzubauen (file1.js ist hier natürlich nur ein Beispielname):
<script language="JavaScript" src="file1.js"
type="text/javascript"></script>
Javascript-Programme sind case-sensitiv, d.h. die Befehle
müssen exakt mit Klein- und Großbuchstaben geschrieben werden (z.B. indexOf,
charAt und so weiter). Javascript ist eine objektorientierte Sprache;
Objekte wie Fenster oder Frames haben "Eigenschaften", die bestimmte
Eigenschaften des Objekts beschreiben oder verändern können, und es gibt
"Methoden", die irgend etwas mit den Objekten tun. So kann man etwa mit der
Anweisung
window.location.href="www.telekom.de/";
den Browser veranlassen, die Eigenschaft href (die Adresse) des
Objekts location auf die Telekom-Homepage zu setzen und somit zu ihr
zu springen. location ist seinerseits ein Objekt, das in der
Hierarchie unterhalb des window-Objekts liegt, also zum jeweils
offenen Browser-Fenster gehört.
Javascript benutzt Variant-Variablen, das bedeutet, eine Variable hat keinen bestimmten Typ, sondern kann entweder eine Zahl oder eine Zeichenfolge aufnehmen. Variablen brauchen vor der Verwendung nicht deklariert werden, wenngleich das mit der Anweisung var durchaus möglich ist und der Übersichtlichkeit dient. Anweisungen müssen, wenn in derselben Zeile weitere folgen, mit einem Semicolon enden; man kann sich das aber auch zur generellen Gewohnheit machen.
Wie auch zu HTML gibt es im Web und in Buchform eine ganze Reihe von Abhandlungen zu Javascript bzw. JScript, nicht zuletzt natürlich von Netscape und Microsoft, so dass an dieser Stelle auf eine ausführliche Sprach-Referenz verzichtet wird.
Java hat trotz des ähnlichen Namens wenig mit Javascript gemein. Diese Sprache, die in Applets (Code, der im Browser ausgeführt wird) und Servlets benutzt wird (Code, der auf dem Server ausgeführt wird), wird nicht wie Javascript zur Laufzeit als Quelltext interpretiert, sondern während der Entwicklung in in einen effizienten Zwischencode (Byte-Code) vorcompiliert, der wesentlich schneller ausgeführt werden kann. Dafür benötigt man allerdings eine eigene Entwicklungsumgebung, weshalb Java trotz seiner Bedeutung an dieser Stelle nur am Rande erwähnt wird.
Durch Verbinden von Javascript und Java - Netscape nennt das Liveconnect - kann man Dinge tun, die von manchen gutgläubigen Menschen für unmöglich gehalten werden, so etwa das Ermitteln der E-Mail-Adresse. Ein Beispiel, das so allerdings nur mit Netscape-Browsern funktioniert:
| <html><body><script language="JavaScript"><!-- function readPref(prefName) { privName = "UniversalPreferencesRead"; netscape.security.PrivilegeManager.enablePrivilege(privName); alert("Mail-Adresse: " + navigator.preference(prefName)); } //--></script><p> <a href="javascript:readPref('mail.identity.useremail')">Test</a> </p></body></html> |
Wenn man diesen Code als HTML-Datei speichert, sie in den Netscape-Browser lädt und auf den enthaltenen Link "Test" klickt, wird nach einer (abschaltbaren) Sicherheitsabfrage die E-Mail-Adresse des Benutzers in einem Message-Fenster angezeigt.
Das Programm funktioniert nur als lokale Datei. Versucht man, es mit einer http-Adresse von einem Web-Server auszuführen, bricht der Browser die Ausführung sofort ab. Es gibt allerdings bei einigen Browser-Versionen Methoden, die diese Sperre aushebeln.
VBScript ist eine von Visual Basic abgeleitete Programmiersprache, die bisher nur vom Microsoft Internet Explorer interpretiert wird. Aus diesem Grunde ist es nicht besonders zweckmäßig, Seiten ins Web zu stellen, die auf VBScript basieren und somit einen damit kompatiblen Browser voraussetzen - man würde damit einen erheblichen Teil der Besucher aussperren.
Das Einbetten von VBScript-Programmen in HTML funktioniert genauso wie bei Javascript. Mit dem Button "Test" können Sie das Script ausprobieren, sofern Sie den Microsoft Internet Explorer benutzen:
Ein Unterprogramm ohne Rückgabewert wird in VBScript mit sub
eingeleitet und mit end sub beendet. Statt alert heißt die
Anweisung zum Anzeigen eines Meldungsfensters hier msgbox. Die Zeile
unter end sub beginnt mit einem Apostroph, da dies in Visual Basic das
Zeichen für einen Kommentar darstellt und der Rest der Zeile so vom Interpreter
ignoriert wird. Der Button "Test" wurde hier mit folgender HTML-Anweisung
realisiert:
<input type="button" value="Test" onclick="vbfenster()">
Beim Microsoft Internet Explorer ab Version 5 kann man HTML-Dateien mit eingebettenen Javascript- oder VBScript-Programmen von der lokalen Festplatte wie eine normale ausführbare Applikation starten, wenn sie die Endung .HTA (HTML Application) besitzen. Dadurch kann man auf einfache Weise kleine interaktive Anwendungen erstellen, für die jene Sicherheitsbeschränkungen, wie sie für HTML-Dateien im Internet absichtlich existieren, nicht gelten. Solche Applikationen sehen auch nicht wie ein Browser aus, sondern wie eine normale Windows-Anwendung.
<html><head><title>Test-Applikation</title>
<HTA:APPLICATION ID="TEST" APPLICATIONNAME="HTA-Beispiel"
BORDER="thick" BORDERSTYLE="normal" CAPTION="YES" ICON="shamrock.ico"
MAXIMIZEBUTTON="YES" MINIMIZEBUTTON="YES" SHOWINTASKBAR="YES"
SINGLEINSTANCE="NO" SYSMENU="YES" VERSION="1.00" WINDOWSTATE="normal">
</head><body onload="setTimeout('check()',5000)">
<script language="JavaScript"><!--
function check()
{ txt = parent.ifr.document.body.innerHTML; // Seiteninhalt
keyw = "Shamrock"; // zu suchendes Wort
if (txt.indexOf(keyw)<0) a=" nicht"; else a="";
alert("Die Seite enthält"+a+" das Wort "+keyw);
}
// --></script>
<IFRAME SRC="http://www.domain.de/seite.htm" name="ifr"
width=242 height=305 align=left hspace=20 vspace=0></iframe>
<p>Testseite</p>
</body></html>
|
Wenn man diese Zeilen als HTA-Datei speichert und aus Windows startet, lädt sie zunächst als "iframe" (das ist eine Sonderform von Frames, die beim Internet Explorer möglich ist) in ein Fenster innerhalb der Seite und prüft nach fünf Sekunden, ob ein bestimmtes Stichwort im Text dieser Webseite vorkommt. Eine "normale" HTML-Datei dürfte das nicht tun, weil für sie aufgrund von Sicherheits-Beschränkungen der Zugriff auf Inhalte anderer Domains gesperrt ist; für ein HTA-Script gelten diese Einschränkungen dagegen nicht. Das HTA-Beispiel enthält im Header auch einige zusätzliche Angaben, die das Aussehen und Verhalten der Applikation bestimmen.
Die Programmiersprache Perl (Practical Extraction and Report Language) wird im Gegensatz zu Javascript, JScript und VBScript ausschließlich auf dem Web-Server ausgeführt. Die Ausgabe eines Perl-Programms erfolgt entsprechend dem CGI-Standard (Common Gateway Interface) über die Standard-Ausgabe (STDOUT) des jeweiligen Betriebssystems. Sie wird vom Web-Server zum Browser z.B. als HTML-Seite durchgereicht.
Umgekehrt kann ein Perl-Programm Eingaben von einem Formular auf einer Web-Seite mit <form action="get"> über die Environment-Variable QUERY_STRING oder mit <form action="post"> über die Standard-Eingabe (STDIN) übernehmen. Damit das Programm bei STDIN weiß, wo die Daten zu Ende sind, wird die Datenlänge zusätzlich in der Environment-Variablen CONTENT_LENGTH übergeben. Der vom Perl-Programm dadurch erhaltene Übergabe-String enthält jeweils durch "&" getrennt die Namen und Werte der im Formular enthaltenen Elemente, hier "Textfeld" und "Button"; Leerzeichen in übergebenen Strings werden durch "+" ersetzt, Umlaute durch %XX als Hex-Code.
Wenn der Client-Browser ein Perl-Programm auf dem Web-Server aufruft, muss das Perl-Programm eine vollständige HTML-Seite inklusive eines Mindest-HTTP-Headers als Antwort zurückliefern. Der HTTP-Header gibt den Informationstyp an (meist text/html), danach folgen zwei Zeilenumbrüche als Header-Endekennzeichen (\n\n), und schließlich der HTML-Text der Ergebnisseite.
Jedes Perl-Programm beginnt mit einer Zeile wie dieser:
#!/usr/bin/perlSie nennt dem Web-Server das Verzeichnis (hier /usr/bin/perl), wo er
einen geeigneten Interpreter für die Perl-Datei finden kann. Im sonstigen
Script-Text dient die Raute # zur Kennzeichnung von Kommentaren.
Ohne auf Details einzugehen, sei hier als Beispiel ein Perl-Programm vorgestellt, das dem Besucher der Seite sagt, welcher Typ von Web-Server hier läuft, über welchen Internet-Provider die Verbindung aufgebaut wurde, welchen Browser-Typ der Client benutzt und ein paar interessante Dinge mehr. Die letzte Anweisung "exit(0)" sagt dem Web-Server, dass das Programm erfolgreich beendet wurde.
| #!/usr/bin/perl print "Content-type: text/html\n\n"; print "<html><head><title>Informationen</title></head>"; print "<body bgcolor=\"#FFEEC4\">\n"; print "<h2>Server- und Browser-Informationen</h2>"; print "<h3>Web-Server:</h3><table border=0 cellpadding=1>"; print "<tr><td>Software:</td><td>$ENV{'SERVER_SOFTWARE'}</td></tr>"; print "<tr><td>Domain-Name:</td><td>$ENV{'SERVER_NAME'}</td></tr>"; print "<tr><td>Server-Port:</td><td>$ENV{'SERVER_PORT'}</td></tr>"; print "</table><h3>Ihr Web-Zugang:</h3><table border=0 cellpadding=1>"; print "<tr><td>IP-Adresse:</td><td>$ENV{'REMOTE_ADDR'}</td></tr>"; print "<tr><td>Provider:</td><td>$ENV{'REMOTE_HOST'}</td></tr>"; print "<tr><td>Browser:</td><td>$ENV{'HTTP_USER_AGENT'}</td></tr>"; print "</table><p><a href=\"/\">Zur Startseite</a>"; if ($ENV{'HTTP_REFERER'} ne '') { print" - <a href=\"$ENV{'HTTP_REFERER'}\">Zurück</a>"; } print "</p></body></html>"; exit (0); |
Perl-Programme werden auf dem Web-Server meist in einem Unterverzeichnis
/cgi-bin gespeichert. (Alle Dateiangaben und Seiten-Referenzen
im Script müssen entweder relativ zu diesem Verzeichnis oder absolut mit
vorangestelltem Schrägstrich erfolgen!) Nach dem Übertragen des Programms,
nennen wir es environ.pl, muss man bei einem unter Unix oder Linux laufenden
Web-Server meist noch dafür sorgen, dass die Datei das Attribut "ausführbar"
enthält. Dies erreicht man durch folgende Unix-Anweisung:
chmod +x environ.pl
Falls Ihr FTP-Programm numerische Werte für die Dateiattribute zulässt,
geht es gewöhnlich so:
chmod 755 environ.plIn FTP-Programmen mit ankreuzbaren Datei-Attributen muss die Einstellung
so lauten:
| chmod | Owner | Group | Other |
| Read | x | x | x |
| Write | x | ||
| Execute | x | x | x |
Eine mögliche Falle ist noch, dass die Perl-Datei auf Unix-Rechnern nur Line Feeds als Zeilentrennung enthalten darf. Wenn Sie das Perl-Programm auf einem Windows-Rechner erstellt haben, der CR+LF zwischen den Zeilen benutzt, achten Sie darauf, beim FTP-Programm den ASCII-Modus zu benutzen, der die CR-Steuerzeichen entfernt.
Perl-Programme müssen nicht notwendigerweise Textausgaben zurückliefern. Das folgende Beispiel-Script, nennen wir es showgif.pl, liefert beim Aufruf aus einer HTML-Seite mit <img src="cgi-bin/showgif.pl"> die Bilddatei bild.gif zurück:
| #!/usr/bin/perl print "Content-Type: image/gif\n\n"; # HTTP-Header+Leerzeile open IN, "/pic/bild.gif" || die; # Pfad relativ zu /cgi-bin! while( <IN> ) { print; } # Gibt den Inhalt der Bilddatei aus close IN; exit (0); |
Während die obigen Beispielprogramme noch halbwegs verständlich sind, sei nicht verschwiegen, dass man zahlreichen Perl-Konstrukten kaum ansieht, was sie eigentlich tun, und das Programmieren in Perl ist sicher eine der anspruchsvolleren Aufgaben für einen Web-Designer.
Eine ganz einfache Methode, auf dem Web-Server Informationen dynamisch in eine HTML-Seite einzufügen, sind Server-Side Includes. Solche HTML-Dateien müssen bestimmte Datei-Endungen haben (typisch .shtml oder .sht), damit der Server weiß, dass er bestimmte Schlüsselworte darin als Anweisungen interpretieren darf. Diese sind im Text als HTML-Kommentare eingebunden, so dass sie nur vom Server beachtet und vom Browser ignoriert werden. Ein paar Beispiele:
| SSI-Zeile in der HTML-Datei | Wirkung |
| <!--#config errmsg="Syntaxfehler"--> | SSI-Fehlermeldung festlegen |
| <!--#config timefmt="%d.%m.%Y %H:%M"--> | Zeitausgabeformat festlegen |
| <!--#config sizefmt="bytes"--> | Dateilängen in Bytes azeigen |
| <!--#config sizefmt="abbrev"--> | Dateilängen in KByte anzeigen |
| <!--#fsize file="test.zip"--> | Anzeige der Länge einer Datei |
| <!--#echo var="DATE_LOCAL"--> | Ausgabe der lokalen Zeit |
| <!--#echo var="DATE_GMT"--> | Ausgabe der Weltzeit (GMT) |
| <!--#echo var="LAST_MODIFIED"--> | Änderungsdatum der akt. Datei |
| <!--#flastmod file="index.htm"--> | Änderungsdatum einer and.Datei |
| <!--#include virtual="teil2.htm"--> | Fügt den Inhalt einer Datei ein |
| <!--#exec cmd="bin/search.exe *.htm"--> | Startet eine ausführbare Datei |
| <!--#exec cgi="/cgi-bin/environ.pl"--> | Führt ein CGI-Programm aus |
<!--#printenv --> |
Environment-Variablen anzeigen |
<!--#set var="x" value="abc" --> |
Setzt einen Variablen-Wert |
Zusätzlich gibt es auch noch die Möglichkeit von Bedingungen nach dem Schema if, elif (else-if) und else:
| <!--#if x="wert1" -->Bedingung 1 ist erfüllt <!--#elif x="wert2" -->Bedingung 2 ist erfüllt <!--#else -->Keine der obigen Bedingungen trifft zu <!--#endif --> |
Die Ausgabe des vom SSI-Element erzeugten Textes erfolgt genau an der Stelle der HTML-Datei, an der das Element steht. Allerdings sind Server-Side Includes aus Sicherheitsgründen nicht auf allen Web-Servern freigeschaltet. Darüber hinaus unterscheiden sich die zur Verfügung stehenden SSI-Anweisungen je nach Server-Software erheblich. Die obige Liste gilt deshalb ausschließlich für Apache-Server ab Version 1.2. Andere Server benutzen zum Teil eine andere Syntax.
Ähnlich wie Perl wird die Script-Sprache PHP auf dem Web-Server ausgeführt, und ähnlich wie bei SSI wird der PHP-Code in HTML eingebettet. Der Server erkennt PHP-Seiten an ihrer Dateiendung (je nach Version z.B. .php3 oder .php4). Im HTML-Code beginnen PHP-Anweisungen mit <? oder <?php und enden mit ?>. Der Server sendet die PHP-Abschnitte nicht an den Browser des Benutzers, sondern interpretiert sie. Beispiel für einen Abschnitt einer Web-Seite, die die Browser-Version des Benutzers anzeigt:
Ihr Browser: <?php echo $HTTP_USER_AGENT; ?>
Die folgende Sequenz gibt einen passenden Text aus, wenn der Benutzer einen Internet Explorer von Microsoft verwendet:
<?php
if (strstr($HTTP_USER_AGENT,"MSIE"))
{ echo "Sie benutzen den Internet Explorer.<br>"; }
?>
Da PHP einen wesentlich größeren Befehlsumfang als SSI besitzt, ist seine Leistungsfähigkeit mit Perl vergleichbar, besitzt aber den Vorteil, dass es wie SSI direkt in HTML-Seiten integriert werden kann. Eine besondere Stärke ist auch die Möglichkeit von Datenbank-Zugriffen (SQL).
Was haben Cookies mit Script-Sprachen zu tun? Nun, man benutzt gewöhnlich Scripts, um Cookies zu schreiben oder zu lesen, deshalb werden sie im Abschnitt über Script-Sprachen erwähnt.
Was ist ein Cookie? Eine Textzeile einer Datei im Browser-Verzeichnis Ihres Computers, die HTTP- oder script-gesteuert erzeugt und gelesen werden kann und einer bestimmten Web-Adresse zugeordnet ist. Darin kann sich ein Web-Server irgendwelche Dinge merken, bis man ihn irgendwann erneut besucht. Zum Beispiel kann der Server Ihre auf einer Mitteilungs-Seite einmal eingegebene Mail-Adresse in einem Cookie auf Ihrem PC speichern, damit das entsprechende Feld beim nächsten Besuch derselben Seite automatisch passend ausgefüllt wird.
Manche Web-Server benutzen Cookies auch, um die Zahl unterschiedlicher Besucher festzustellen. Dazu wird beim ersten Besuch der Seite einfach ein Cookie gespeichert, sein Name ist meist WEBTRENDS_ID. Ein neuer Besucher ist dann einfach einer, bei dem dieses Cookie noch fehlt. Dadurch kann man die "echte" Besucherzahl besser von der Zahl der Seitenabrufe unterscheiden. (Da viele Anwender Cookies im Browser allerdings deaktiviert haben, ist der Mechanismus etwas fragwürdig.)
Cookies sind im Prinzip ungefährlich, in der Größe auf 4 KByte begrenzt und können keinen ausführbaren Code, sondern nur einfache Wert-Zuweisungen enthalten, zum Beispiel "Vorname=Albert" oder "Mail=abc@example.com". Es ist einem Web-Server normalerweise nicht möglich, Cookies auszulesen, die von einem Server mit einem anderen Domain-Namen erzeugt wurden. Bedenken sollte man allerdings, dass viele Server Werbe-Grafiken von einer anderen Domain laden, die dann ebenfalls Cookies speichern kann, wenn die Grafik mit einem CGI-Script realisiert wird.
Wenn ein Web-Server den Browser veranlassen will, ein Cookie zu speichern,
liefert er im HTTP-Header zusätzlich eine Zeile "Set
Cookie":
Set-Cookie: Name=Wert; path=/; expires=Mon, 09-Dec-2002 13:46:00 GMT
"Name" steht dabei für den Namen des Cookies, "Wert" für einen numerischen oder alphanumerischen Wert, "path" gibt an, welche Seiten (hier alle derselben Domain) später auf das Cookie zugreifen dürfen, und "expires" sagt dem Browser, wann er das Cookie wieder löschen darf. Wenn expires=... fehlt, wird das Cookie nur bis zum Beenden des Browsers gespeichert.
Wenn der Browser später den Inhalt eines Cookies zum Server schickt, sendet
er ebenfalls einen HTTP-Header, in dem ebenfalls zusätzlich der Cookie-Name und
sein Wert stehen:
Cookie: Name=Wert
In Perl kann man Cookies ganz leicht erzeugen, da ein Perl-CGI-Programm auf dem Server den HTTP-Header selbst generiert; somit kann man auch "Set-Cookie: ..." hineinschreiben. Das Lesen von Cookies erfolgt in Perl über die Environment-Variable $ENV{'HTTP_COOKIE'}, sie liefert das Ergebnis wieder in der Form Name=Wert.
In Javascript oder VBScript
kann ein Cookie ganz einfach mit Hilfe von document.cookie gelesen
oder geschrieben werden. Die Anweisung zum Schreiben kann zum Beispiel so
aussehen:
document.cookie="Name=Wert; path=/; expires=Mon, 01-Jan-2001 00:00:00 GMT"
Ob ein Cookie zur eigenen Domain bzw. Seite existiert, kann man einfach mit
if (document.cookie) abfragen. Das Lesen erfolgt wieder durch Auslesen
des Werts von document.cookie, wobei man eine Zeichenfolge der Form
Name=Wert erhält. Wenn Cookies im Browser deaktiviert sind, führen diese
Anweisungen nicht zu einer Fehlermeldung, sondern werden einfach ignoriert.
Falls dieselbe Domain mehrere Cookies erzeugt hat, werden sie in der Form
Name1=Wert1; Name2=Wert2; Name3=Wert3
gemeinsam zurückgeliefert, zum Beispiel:
Vorname=Albert; Nachname=Einstein; Mail=albert@example.com
Um ein Cookie scriptgesteuert zu löschen, kann man entweder seinen Wert auf einen Leerstring setzen oder das Verfalldatum auf einen Wert in der Vergangenheit ändern. Um dagegen alle Cookies des Browsers manuell zu löschen, muss man bei Netscape die Datei Cookies.txt löschen und beim Microsoft Internet Explorer alle Dateien im Windows-Unterverzeichnis Cookies entfernen, nachdem man den Browser beendet hat.
Konzeptionell weisen Script-Sprachen und Cookies eine hohe Sicherheit gegen das Ausspionieren persönlicher Daten und sonstige Angriffe auf den eigenen Rechner auf. So sind etwa Zugriffe auf lokale Dateien mit Javascript nur möglich, wenn die HTML-Datei, die das Script enthält, selbst als lokale Datei vorliegt. Es haben sich allerdings immer wieder Fehler in marktüblichen Browsern herausgestellt, die gewieften Hackern ein Umgehen dieser Sicherheits-Barrieren ermöglichen.
Die häufigste Ursache von Sicherheitslücken ist ein sogenannter Buffer Overflows (Pufferüberlauf) - ein für die Programmiersprache C leider typisches Problem, da sie im Gegensatz zu C++, C#, Java, Delphi oder Basic keinen echten String-Datentyp aufweist: Zeichenfolgen müssen statt dessen gewöhnlich in Puffern abgelegt werden, deren Länge der Programmierer sich anhand typischer Szenarien vorher überlegt hat. Wenn ein Angreifer nun einen längeren String einschleust und im Programm (z.B. im Browser) das Überschreiten der Maximallänge nicht geprüft wird (nach dem Motto "eine so lange Zeichenfolge kann ja eigentlich nicht vorkommen"), überschreiben Teile der Daten andere Speicherbereiche. Besonders anfällig dafür ist der Stack-Bereich, auf dem nicht nur temporäre Variablen, sondern auch Rücksprungadressen von Funktionen abgelegt werden. Auf diese Weise war es Angreifern bereits wiederholt möglich, eigenen Code auf den Stack zu schmuggeln und diesen durch Überschreiben von Rücksprung-Adressen zu starten.
Um sich eine derartige Infektion einzufangen, genügt oftmals der einfache Besuch einer Webseite oder der Erhalt einer HTML-formatierten E-Mail. Besonders gefährlich sind sogenannte Trojaner, die sich mit solchen Mechanismen unbemerkt auf dem PC einnisten und persönliche Informationen auslesen - besonders gefragt sind Informationen über Online-Banking-Aktivitäten, wobei Keylogger die Tastendrücke protokollieren dann unbemerkt über das Internet versenden.
Der sicherste Ausweg ist im Prinzip, Javascript (bzw. Active Scripting bei Microsoft), Java und Cookies nur bei vertrauenswürdigen Domains zuzulassen und ansonsten generell zu deaktivieren und ferner empfangene Mails nur im Textmodus und nicht HTML-formatiert anzuzeigen. Allerdings verlassen sich inzwischen viele Webseiten bei der Navigation auf Javascript, so dass man gut beraten ist, einen Browser einzusetzen, der sich in der Vergangenheit als sicherheitstechnisch unkritisch erwiesen hat, z.B. Opera.
WAP
2.0 und XHTML Mobile Geräte, insbesondere GSM-Handys, benutzen meist ein spezielles Verfahren zum Internet-Zugang, das an ihre begrenzten Speicher- und Prozessor-Möglichkeiten angepasst ist, das "Wireless Application Protocol" (WAP). Für die an das kleine Handy-Display angepassten Internet-Seiten wurde ursprünglich die "Wireless Markup Language" (WML) erfunden: In den Gateway-Rechnern der GSM-Netzbetreiber wurden WML-Seiten aus dem Internet vor dem Senden ans Endgerät komprimiert; dabei wurden die WML-Tags wie etwa <p> jeweils in einen 1-Byte-Code übersetzt, um Übertragungszeit zu sparen. WAP 1.0/1.1/1.2 und das dazugehörige WML haben sich allerdings trotz anfänglicher Erfolge nicht auf breiter Front durchsetzen können.
Deshalb wurde mit WAP 2.0 ein neuer, dem herkömmlichen HTML (oder genauer: XHTML) wesentlich ähnlicherer Standard entworfen, der inzwischen größere Akzeptanz findet. XHTML ist eine in eine XML-Struktur eingebettete HTML-Variante. Wesentliche Eigenschaften sind:
WAP-2.0-Seiten sollten ferner grundsätzlich UTF-8 als Codierung verwenden;
beispielsweise werden deutsche Umlaute dabei in einem 2-Byte-Code dargestellt.
In Perl ist die Umwandlung von ISO-8859-1 in UTF-8 ein
kompakter Einzeiler:
$text=~s/([\x80-\xFF])/chr(0xC0|ord($1)>>6).chr(0x80|ord($1)&0x3F)/eg;
Hier ist als kleines Beispiel das Gerüst einer typischen WAP-2.0-XHTML-Datei:
<?xml version="1.0" encoding="UTF-8"?> |
Generell gelten für Inhalte, die auf mobilen Endgeräten gut und schnell darstellbar sein sollen, folgende Empfehlungen:
# Root-Aufruf mobiler Geräte zu XHTML-Seite umlenken |
Beim Apache-Server kann man mit Hilfe einer Datei .htaccess dafür sorgen, dass HTML-Browser eine andere Seite angezeigt bekommen (siehe Beispiel rechts). Dabei wird ein mobiler Browser beim Arufruf der Domain, falls dahinter kein Dateiname angegeben wird, automatisch zu einer Seite "pda.xhtml" umgeleitet, die die Inhalte in einem passenden Format enthält, z.B. als WAP 2.0.
Inhaltsverzeichnis/Copyright - © Shamrock Software GmbH - Das Kopieren des Inhalts auf andere Websites ist nicht gestattet.