Ongate ? Hat jemand Erfahrungen mit dieser Firma?
abrahamus
habe denen viel geld für eine suchmaschinenoptimierung bezahlt und
habe keine leistung erhalten. das ganze geht jetzt vor gericht.
allerdings sagt mein anwalt, das es schlecht aussieht, da die einen
guten vertrag mit mir abgeschlossen haben. ich bin eben einfach zu
leichtsinnig und vertraue zu schnell. kann mir jemand tips geben, wie
ich mich nun verhalten soll? hat jemand ähnliche erfahrungen mit der
firma ongate aus frankfurt gemacht?
Alexander Schestag
abrahamus wrote:
> hat jemand erfahrung mit der seo firma ongate ( www.ongate.eu) ?
Nein. Und ich rate davon ab, in offenen Streitfällen öffentlich Namen zu
nennen, wenn du am Ende nicht noch Ärger wegen Geschäftsschädigung
bekommen willst.
> kann mir jemand tips geben, wie ich mich nun verhalten soll?
Dazu müßte man mehr Details über den Sachverhalt wissen. Aber das ist
ein Fall für einen Anwalt bzw. eine Rechtsberatung. Sowas können wir
hier nicht leisten.
Grüße,
Alex
Ina Koys
> hat jemand erfahrung mit der seo firma ongate ( www.ongate.eu) ? ich
> habe denen viel geld für eine suchmaschinenoptimierung bezahlt und
> habe keine leistung erhalten. das ganze geht jetzt vor gericht.
> allerdings sagt mein anwalt, das es schlecht aussieht, da die einen
> guten vertrag mit mir abgeschlossen haben. ich bin eben einfach zu
> leichtsinnig und vertraue zu schnell.
Mir hätte ein Blick auf deren Webseite genügt um festzustellen, dass die
keine Ahnung haben. Hättest du mal vorher noch jemand anderen gefragt,
der hätte das auch gesehen.
kann mir jemand tips geben, wie
> ich mich nun verhalten soll?
Da wir den Vertrag nicht kennen, wird dir wahrscheinlich nur dein Anwalt
sinnvoll raten können. Hast du den wenigstens etwas gründlicher abgeklopft?
hat jemand ähnliche erfahrungen mit der
> firma ongate aus frankfurt gemacht?
Nein, aber unter den SEOs gibt es eine Menge Möchtegerns, wahrscheinlich
mehr als seriöse. Und welche, die dich anspammen ("Wir bringen Sie in
die 10.000 wichtigsten Suchmaschinen / Ihre Seite ist nicht in Google
gelistet!") kannst du schon mal unbesehen in die Tonne treten.
Ina
--
"Wer mit seinem Garten zufrieden ist, verdient ihn nicht!"
(Karl Foerster)
http://www.koys.de/Pflanzentausch/
Hermann Rokicz
URLs aus der Googlesuche nach "Ongate":
http://www.ice-blog.de/283-ongate-gmbh-schickt-mir-unaufgefordert-e-mails
http://forums.oscommerce.de/index.php?showtopic=53243
http://www.xt-commerce.com/forum/showthread.php?t=45946&page=4
http://www.ayom.com/topic-18091.html
http://www.yoome.de/thread.php?threadid=997&threadview=0&hilight=&hilightuser=0&page=1
Vermutlich wird sich Herr Rechtsanwalt Grau bald bei dir melden und
verlangen, dass Dein Beitrag zurück gezogen wird.
Gruß Hermann!
stefano picco
Hermann Rokicz schrieb:
> URLs aus der Googlesuche nach "Ongate":
>
> http://www.ice-blog.de/283-ongate-gmbh-schickt-mir-unaufgefordert-e-mails
> http://forums.oscommerce.de/index.php?showtopic=53243
> http://www.xt-commerce.com/forum/showthread.php?t=45946&page=4
> http://www.ayom.com/topic-18091.html
> http://www.yoome.de/thread.php?threadid=997&threadview=0&hilight=&hilightuser=0&page=1
auweia, das scheint ja ein sehr nettes Unternehmen zu sein. Und was ich
bisher an eigenen Recherchen zu deren "optimierten" Seiten gesehen habe
ist eher reine Suchmaschinen Logik und keine spezielle Optimierung. Wäre
interessant zu wissen ob das Unternehmen auch schon mal abgemahnt oder
verklagt worden ist :)
> Vermutlich wird sich Herr Rechtsanwalt Grau bald bei dir melden und
> verlangen, dass Dein Beitrag zurück gezogen wird.
Nunja, dieser ist doch jetzt bereits in zig Usenet Archiven gespeichert
oder? Der RA kann ja mal versuchen weltweit alles aus diesen Archiven
löschen zu lassen, somit hat er direkt ein neues Hobby bis an sein
Lebensende.
Aber die scheinen eine sehr gute Sales und Marketing Abteilung zu haben,
denn anscheinend gibt es doch einige Unternehmen, die das Angebot in
Anspruch genommen haben. Dafür muß man denen Respekt zollen, grade bei
der Fülle an Unternehmen die die selbe Dienstleistung anbieten!
bye
Stefano
--
business: spicOne multimedia http://www.spicone.de - http://www.spic.de
projects: http://www.mythos77.de - http://www.typopolis.de
private: http://blog.stefano-picco.de - http://spicone.deviantart.com
Wolfgang Ewert
> ich habe denen viel geld für eine suchmaschinenoptimierung bezahlt
> und habe keine leistung erhalten.
2000 Euronen AFAIK.
Bringt mich wieder zu der Frage, ob man die SE-"Optimierung" selber
machen oder delegieren sollte. Ich bin immer noch bei Ersteres, sehe da
auch keinen Anlass zum Wechsel der "Strategie", die ich immer noch so
simpel und stupid mache wie beim Aufkommen der SE's:
1) "Griffigen" Text und SE-taugliche Verlinkung auf den eigenen Seiten
anbieten.
2) Link-Partner suchen, die aus eigenem und gegenseitigem Interesse
(d.h. es besteht auch außerhalb der Verlinkung eine Affinität zwischen
den Linkpartnern) verlinken.
3) Ruhe bewahren, ggf. Trefferstatistik und Suchbegriffe, die *wirklich*
benutzt werden, beachten ggf. berücksichtigen.
3a) Teile des Inhalts konstant lassen, Teile aktualisieren (wie es real
anfällt); registrieren, wie die SEs das würdigen.
3b) Fehler im Auftritt, die zu einem Ignorieren oder Herabstufen bei den
SEs führt, korrigieren (bei mir war es das meta name="description"
content="" bei Yahoo und msn).
4) Weiter bei Punkt 3.
Dieses 5-Minuten-Programm (das Tippen hier braucht länger) toppt mir
keine kommerzielle SE-Optimierung.
Wolfgang
--
Nirgendwo hängt der Schulerfolg so stark von Einkommen und Vorbildung
der Eltern ab wie in D'land. Das dt. Schulsystem versagt bei der
Förderung von Arbeiter- und Migrantenkindern. (dpa/FTD 22.11.04)
Michael Fesser
>Bringt mich wieder zu der Frage, ob man die SE-"Optimierung" selber
>machen oder delegieren sollte. Ich bin immer noch bei Ersteres, sehe da
>auch keinen Anlass zum Wechsel der "Strategie", die ich immer noch so
>simpel und stupid mache wie beim Aufkommen der SE's:
ACK
>1) "Griffigen" Text und SE-taugliche Verlinkung auf den eigenen Seiten
>anbieten.
Sowieso. Was der allgemeinen Benutzerfreundlichkeit zugute kommt, ist
auch für SEs nicht schlecht.
>2) Link-Partner suchen, die aus eigenem und gegenseitigem Interesse
>(d.h. es besteht auch außerhalb der Verlinkung eine Affinität zwischen
>den Linkpartnern) verlinken.
>3) Ruhe bewahren, ggf. Trefferstatistik und Suchbegriffe, die *wirklich*
>benutzt werden, beachten ggf. berücksichtigen.
Das ist IMHO einer der wichtigsten Punkte: Geduld. Übers Knie brechen
kann man sowas nicht, eine gute Platzierung braucht Zeit. Viel Zeit.
Aber die zahlt sich letzten Endes aus.
Micha
Alexander Schestag
Wolfgang Ewert wrote:
> Hallo abrahamus,Du teiltest mit:
>> ich habe denen viel geld für eine suchmaschinenoptimierung bezahlt
>> und habe keine leistung erhalten.
> 2000 Euronen AFAIK.
HIRCH! Für wieviele Einzelseiten?
> Bringt mich wieder zu der Frage, ob man die SE-"Optimierung" selber
> machen oder delegieren sollte.
Wenn man kann, sollte man natürlich selber machen. Den meisten fehlen
aber schon die grundlegendsten Grundlagen. Wie oft bekomme ich
diesbezüglich Anfragen, warum eine Seite nicht in Suchmaschinen
erscheint. Einen Blick drauf geworfen, was sehe ich - oder besser: Was
sehe ich nicht? Auswertbaren Content! Da stehen dann maximal 3 Sätze auf
5 Seiten, der Rest sind Bildchen-Menüs, meist noch ohne alt-Texte, und
Flashfilmchen. Und damit will man in Suchmaschinen.
> 1) "Griffigen" Text und SE-taugliche Verlinkung auf den eigenen Seiten
> anbieten.
Richtig. Und daran hapert es bei den meisten schon, s. o.
[...]
> Dieses 5-Minuten-Programm (das Tippen hier braucht länger) toppt mir
> keine kommerzielle SE-Optimierung.
Ich mache das ähnlich, möchte aber noch einen Punkt ergänzen, den ich
bei der Optimierung für ganz wichtig halte:
- Auf das richtige Verhältnis von "Angebot und Nachfrage" achten.
Sprich: Man sollte auf Begriffe optimieren, zu denen es nicht schon
Millionen Seiten gibt, die aber ganz ordentlich nachgefragt werden.
Damit habe ich bisher sehr gute Erfolge erzielt.
Grüße,
Alex
Wolfgang Ewert
> > 2000 Euronen AFAIK.
>
> HIRCH! Für wieviele Einzelseiten?
k.A. Man bekommt AFAIK Dummy-Domains (als Linkspender??? - siehe
Linkfarm) danebengestellt. Deren Nutzen habe ich beim drüberfliegen
nicht ermitteln können, kann sicher nich mal der Hersteller beziffern.
Ich bin Hermanns Links in die Foren gefolgt - und da tat sich diese o.g.
Größe mehrmals kundtun.
> > Bringt mich wieder zu der Frage, ob man die SE-"Optimierung" selber
> > machen oder delegieren sollte.
>
> Wenn man kann, sollte man natürlich selber machen. Den meisten fehlen
> aber schon die grundlegendsten Grundlagen. [Unzugänglichmachung]
>... Und damit will man in Suchmaschinen.
Yep.
...
> Ich mache das ähnlich, möchte aber noch einen Punkt ergänzen, den ich
> bei der Optimierung für ganz wichtig halte:
>
> - Auf das richtige Verhältnis von "Angebot und Nachfrage" achten.
> Sprich: Man sollte auf Begriffe optimieren, zu denen es nicht schon
> Millionen Seiten gibt, die aber ganz ordentlich nachgefragt werden.
> Damit habe ich bisher sehr gute Erfolge erzielt.
"Alleinstellungsmerkmale"?
ACK, ich sehe das im Zusammenhang mit "ggf. Trefferstatistik und
Suchbegriffe, die *wirklich* benutzt werden, beachten u. ggf.
berücksichtigen."
Wolfgang
Matthias Opatz
>> URLs aus der Googlesuche nach "Ongate":
>>
>> http://www.ice-blog.de/283-ongate-gmbh-schickt-mir-unaufgefordert-e-mails
>> http://forums.oscommerce.de/index.php?showtopic=53243
>> http://www.xt-commerce.com/forum/showthread.php?t=45946&page=4
>> http://www.ayom.com/topic-18091.html
>> http://www.yoome.de/thread.php?threadid=997&threadview=0&hilight=&hilightuser=0&page=1
Erstaunlich, weil in den beiden letztgenannten das Suchwort überhaupt
nicht vorkommt (aber wahrscheinlich gemeint ist).
Matthias
--
Die Regierungen der Päpste waren nur kurz, obgleich immer der Vater
auf den Sohn folgte. Prof. Galletti
Wer zum Kuckuck ist dieser Galletti? => <http://www.galletti.de/>
= Bitte bei Mailantwort Großbuchstaben aus Reply-Adresse löschen. =
Alexander Schestag
> Hallo Alexander Schestag, Du teiltest mit:
>> - Auf das richtige Verhältnis von "Angebot und Nachfrage" achten.
>> Sprich: Man sollte auf Begriffe optimieren, zu denen es nicht schon
>> Millionen Seiten gibt, die aber ganz ordentlich nachgefragt werden.
>> Damit habe ich bisher sehr gute Erfolge erzielt.
> "Alleinstellungsmerkmale"?
> ACK, ich sehe das im Zusammenhang mit "ggf. Trefferstatistik und
> Suchbegriffe, die *wirklich* benutzt werden, beachten u. ggf.
> berücksichtigen."
Ja, ok, darunter kann man es zusammenfassen. Das Problem ist: Viele tun
es nicht. Da wird munter auf einen Begriff optimiert, der in Statistiken
als häufig nachgefragt ausgewiesen ist, und hinterher wundert man sich,
daß da nix kommt. Ja, wie auch, wenn man an Position 14293 von 1228122
steht??? Selbst eine relativ gesehen gute Positionierung macht es in dem
Fall nicht besser. Man muß sehen, daß man die Seite unter dem Begriff
unter die ersten 20-30, besser unter die ersten 10 bringt. Und das geht
um so leichter, je weniger Seiten es zu einem Begriff gibt.
Alex
Stefan Froehlich
> Man muß sehen, daß man die Seite unter dem Begriff unter die ersten
> 20-30, besser unter die ersten 10 bringt. Und das geht um so leichter,
> je weniger Seiten es zu einem Begriff gibt.
Top 10 bei schnitzelmitkartoffelsalat bist, wird sich die Zahl der
daraus generierten Treffer trotzdem in engen Grenzen halten.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Stefan - die grausste kreative Idee des Jahrtausends.
(Sloganizer)
Niels Braczek
> Erstaunlich, weil in den beiden letztgenannten das Suchwort überhaupt
> nicht vorkommt (aber wahrscheinlich gemeint ist).
Warum? Linktexte haben ein nicht unerheblichen Einfluss auf die
Zuordnung von Seiten zu Suchworten.
MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Alexander Schestag
> On Mon, 02 Jul 2007 17:31:28 +0200 Alexander Schestag wrote:
>> Man muß sehen, daß man die Seite unter dem Begriff unter die ersten
>> 20-30, besser unter die ersten 10 bringt. Und das geht um so leichter,
>> je weniger Seiten es zu einem Begriff gibt.
> Das alleine bringt Dich allerdings auch nicht weiter. Wenn Du unter den
> Top 10 bei schnitzelmitkartoffelsalat bist, wird sich die Zahl der
> daraus generierten Treffer trotzdem in engen Grenzen halten.
ACH?! Was meinst du, warum ich schrieb:
> - Auf das richtige Verhältnis von "Angebot und Nachfrage" achten.
> Sprich: Man sollte auf Begriffe optimieren, zu denen es nicht schon
> Millionen Seiten gibt, die aber ganz ordentlich nachgefragt werden.
> Damit habe ich bisher sehr gute Erfolge erzielt.
Alex
Alexander Schestag
> Bietet man SEO als Dienstleistung an, sollte man bei solchen Zahlen,
> also 1,2 Mio. Treffer zum "idealen", häufigst nachgefragten Suchbegriff,
> mittelfristig einen Platz in den TopTen zusagen können.
Das kommt sehr auf die Bedingungen an, die man vortrifft. So etwas geht
m. E. nur mit On-Page-Optimierung nur bedingt. Hat man eine Firma mit
einem eigenen Server vor sich, bei der man auch die Off-Page-Optimierung
komplett steuern kann, ist das durchaus möglich, die Erfahrung hab ich
auch schon gemacht. In vielen Fällen hat man es jedoch mit kleineren
Kunden zu tun, die ihre Domain auf einem Shared-Hosting-Server eines
Massenhosters mit 20.000 anderen Kunden unter der gleichen IP haben und
bei denen Off-Page-Optimierung allenfalls rudimentär möglich ist, weil
man beispielsweise mod_rewrite u. ä. nicht benutzen kann oder etwa nicht
mal das direkte Anlegen einer .htaccess möglich ist. Da würde ich dann
seriöserweise sagen: Vergiß es, es sei denn, du lieferst auf so einer
Seite zu dem Begriff tonnenweise guten Content, der die Konkurrenz um
Längen schlägt.
> Mit "sauberen" Methoden, natürlich, ohne dafür Linkfarmen anzulegen etc.
> Allerdings geht das meist mit einem Umbau oder einer Neugestaltung einher,
> sodass die Preislage den genannten 2k Euro nahe kommt.
Das kommt unter bestimmten Umständen durchaus hin, ja. Im genannten Fall
waren 2k Euro aber maßlos überzogen. Meistens wird das Angebot dann aber
auch abgelehnt, und man sucht sich einen billigeren [tm] Anbieter, der
unsaubere Methoden anwendet.
Grüße,
Alex
sandm...@gmx.de
> ich mich nun verhalten soll? hat jemand ähnliche erfahrungen mit der
> firmaongateaus frankfurt gemacht?
Ich kann dir vielleicht einige Tipps geben, da ich mich mit ongate im
Rechtsstreit befinde. Ich selbst habe auch einen Vertrag
unterschrieben und keinerlei Verbesserung meiner Suchergbnisse
erhalten. Ongate hat mit seiner Technik sogar bewusst die Google
Richtlinien verstoßen, indem sie Zusatzdomains bestellt haben und
diese mit Keywordspam versehen haben. Pikanterweise werben sie damit,
eine Firma bei "Google nach ganz oben zu bringen" Heute bin ich
schlauer und würde von Anfang an fragen, was genau bei der
Suchmaschinenoptimierung gemacht wird. Vorab sollte man sich darüber
im klaren sein, dass der Abmahnanwalt von Ongate Rechtsanwalt Kevin
Grau aus Wiesbaden, ohne Skrupel gegen alle vorgeht, die sich
öffentlich über Ongate äußern. Auch wenn die Äußerungen der Wahrheit
entsprechen (wie bei mir), wird sich auf eine angebliche
Geschäftsschädigung berufen.
Bei mir ging es sogar soweit, dass Herr Rechtsanwalt Grau - der
übrigens auch als Inkassobüro für Ongate fungiert und pikanterweise
Präsidiumsmitglied der Leipziger Akademie für angewandtes
Wirtschaftsstrafrecht ist - meinem Anwalt vorzuwerfen, er würde in der
Ongate-Sache illegal nach Mandanten fischen. (Man läßt nichts
unversucht) Leider hat Herr Grau bei meinem Anwalt den Falschen
erwischt, da mein Anwalt bei unberechtigten Anschuldigungen sehr
ungehalten werden kann und auch nicht davor zurückschreckt einen
Kollegen mit einem Strafverfahren zu überziehen, wodurch Herr Grau
seinen Vorwurf zurück ziehen mußte.
Aufgrund vieler Zuschriften zu Ongate, seit meinen Veröffentlichungen,
weiß ich und kann es belegen, daß der Verkauf immer nach dem gleichen
Prinzip abläuft: 1. Call-Center rufen Interessenten an 2. Es werden
Suchbegriffe auf Position 1 bei Google benannt, um einen Erfolg zu
belegen 3. Interessenten werden exklusive Referenz-Verträge zu
unterschiedlichen Preisen und Rabatten versprochen. 4. Es werden
Keyword-, Webseite- und Konkurrenzanalysen versprochen, die aber nicht
schriftlich dem Auftraggeber mitgeteilt werden. 5. Der Auftraggeber
wird nach Keywords und Gebietsschwerpunkten gefragt, aus denen Ongate
einen Mix aus neuen Keywordkombinationen erstellt (nicht wirklich
kreativ).
Diese vorgehensweise wiederspricht klar den Google Richtlinien und ist
eine Arbeit, die in keiner Weise im Verhältnis zu der Bezahlung steht.
Ganz zu schweigen von der monatlichen Gebühr.
Die Verkaufsweise erinnert sehr an das frühere Verkaufsprinzip von
Drückerkolonnen für Zeitschriften. Die Leistung der
"Webseitenoptimierung" ist vergleichbar mit dem Erstellen eines
normalen Serienbriefes. Bei einem einzelnen Klageverfahren, oder auch
ggf. Strafantrag, hat ein Gericht Schwierigkeiten aus dem Einzelfall
ein identisches "Geschäftsprinzip" zu erkennen. Je mehr Klagen beim
Amtsgericht Frankfurt gegen Ongate eingehen, die immer wieder einen
ähnlichen Inhalt haben und das gleiche Prinzip aufzeigen, um so größer
ist die Chance, ein gewerbsmäßiges Prinzip zu erkennen und die
Schwerpunkt-Staatsanwaltschaft zu strafrechtlichen Ermittlungen zu
bewegen (Frage des öffentlichen Interesses). Es ist daher wichtig, daß
Ongate Geschädigte sich nicht nur in Foren beschweren, sondern Beweise
sammeln, ggf. den Vertrag kündigen und ggf. beim AG Frankfurt eine
Klage gegen Ongate einreichen, um ihr Geld zurück zu verlangen. Ongate
hat bei einer Klage in Frankfurt deswegen einen schweren Stand, da
diese Firma nicht nur eine Dienstleistung, sondern leichtsinnigerweise
auch ein Ergebnis der Dienstleistung zusagt. Dadurch kann auch bei
bereits abgelaufenen Verträgen innerhalb der Verjährungsfrist
rückwirkend das Geld zurück verlangt werden, wenn das zugesagte
Ergebnis nicht erreicht wurde. Ich schätze, das sollte Dir
weitergeholfen haben!
Gustaf Mossakowski
> Hat man eine Firma mit einem eigenen Server vor sich, bei der man
> auch die Off-Page-Optimierung komplett steuern kann, ist das durchaus
> möglich, die Erfahrung hab ich auch schon gemacht. In vielen Fällen
> hat man es jedoch mit kleineren Kunden zu tun, die ihre Domain auf
> einem Shared-Hosting-Server eines Massenhosters mit 20.000 anderen
> Kunden unter der gleichen IP haben und bei denen Off-Page-Optimierung
> allenfalls rudimentär möglich ist, weil man beispielsweise
> mod_rewrite u. ä. nicht benutzen kann oder etwa nicht mal das direkte
> Anlegen einer .htaccess möglich ist.
Bisher war ich nicht mit dem Begriff »Off-Page-Optimierung« vertraut.
Auf einigen Websites, die auf den ersten Plätzen zu dem Thema bei Google
waren, steht, dass es sich hier um eingehende Links und ggf. Linktexte
handelt. Was hat das mit dem Apache-Modul mod_rewrite zu tun? So wie ich
das verstehe, ist doch bei »Off-Page-Optimierung« überhaupt kein Zugriff
auf den Server, auf dem die Website läuft, nötig.
Viele Grüße
Gustaf
Ina Koys
> Das kommt unter bestimmten Umständen durchaus hin, ja. Im genannten Fall
> waren 2k Euro aber maßlos überzogen. Meistens wird das Angebot dann aber
> auch abgelehnt, und man sucht sich einen billigeren [tm] Anbieter, der
> unsaubere Methoden anwendet.
Es gibt auch preiswertere Anbieter, die saubere Methoden anwenden. Frag
meine Kunden :)
Alexander Schestag
Gustaf Mossakowski wrote:
> Alexander Schestag schrieb:
>
>> Hat man eine Firma mit einem eigenen Server vor sich, bei der man
>> auch die Off-Page-Optimierung komplett steuern kann, ist das durchaus
>> möglich, die Erfahrung hab ich auch schon gemacht. In vielen Fällen
>> hat man es jedoch mit kleineren Kunden zu tun, die ihre Domain auf
>> einem Shared-Hosting-Server eines Massenhosters mit 20.000 anderen
>> Kunden unter der gleichen IP haben und bei denen Off-Page-Optimierung
>> allenfalls rudimentär möglich ist, weil man beispielsweise
>> mod_rewrite u. ä. nicht benutzen kann oder etwa nicht mal das direkte
>> Anlegen einer .htaccess möglich ist.
> Bisher war ich nicht mit dem Begriff »Off-Page-Optimierung« vertraut.
> Auf einigen Websites, die auf den ersten Plätzen zu dem Thema bei Google
> waren, steht, dass es sich hier um eingehende Links und ggf. Linktexte
> handelt.
Das ist nur ein Teil der Off-Page-Optimierung.
> Was hat das mit dem Apache-Modul mod_rewrite zu tun? So wie ich
> das verstehe, ist doch bei »Off-Page-Optimierung« überhaupt kein Zugriff
> auf den Server, auf dem die Website läuft, nötig.
Doch. Off-Page-Optimierung ist deutlich mehr, als nur für eingehende
Links zu sorgen. Dazu gehört die richtige Wahl des Domainnamens und der
Verzeichnis- und Dateinamen. Das kann man natürlich auch bei einem
Shared-Hosting-Provider beeinflussen, insofern man Unterverzeichnisse
anlegen darf, was zumindest meiner Erfahrung nach früher nicht überall
erlaubt war. Es gibt aber auch einige Dinge, die über eine .htaccess
laufen müssen, wie Redirects oder das "suchmaschinenfreundliche"
Umschreiben von URLs. Nimm den Fall, daß du ganz furchtbare, dynamisch
generierte URLs der Form http://www.bla.de/blubb.php?blibb=1&blebb=2
hast. Google hatte mit sowas lange Probleme (und hat sie wohl teilweise
noch), andere Suchmaschinen haben diese Probleme nach wie vor. Deswegen
sollte man solche URLs "suchmaschinenfreundlich" umschreiben. Das macht
man in der Regel mit mod_rewrite in einer .htaccess. Wenn der Hoster
aber weder mod_rewrite noch die Möglichkeit, eine .htaccess anzulegen,
anbietet, geht das nicht. Gleiches gilt für Redirects. Es gibt Hoster,
die erlauben das Einstellen von Redirects nur über ein Webinterface ohne
direktes Anlegen der .htaccess. Da kann ein Redirect leicht nach hinten
losgehen.
Grüße,
Alex
Alexander Schestag
Axel Joensson wrote:
>> In vielen Fällen hat man es jedoch mit kleineren
>> Kunden zu tun, die ihre Domain auf einem Shared-Hosting-Server eines
>> Massenhosters mit 20.000 anderen Kunden unter der gleichen IP haben und
>> bei denen Off-Page-Optimierung allenfalls rudimentär möglich ist, weil
>> man beispielsweise mod_rewrite u. ä. nicht benutzen kann oder etwa nicht
>> mal das direkte Anlegen einer .htaccess möglich ist. Da würde ich dann
>> seriöserweise sagen: Vergiß es, es sei denn, du lieferst auf so einer
>> Seite zu dem Begriff tonnenweise guten Content, der die Konkurrenz um
>> Längen schlägt.
> Entspricht nicht meiner Erfahrung. Sämtliche meiner Kunden haben
> ausgesprochen preisgünstige Shared-accounts um die 2 EUR/Monat,
> ..htaccess-Zugang brauche ich meist nur, um alte Dateinamen ggf. auf neue
> umzuleiten.
Was machst du mit dynamisch generierten, suchmaschinenunfreundlichen
URLs, wenn du kein mod_rewrite und keine .htaccess zur Verfügung hast?
IMO bleibt dann nur Umschreiben des Codes, sodaß andere URLs generiert
werden, die brauchbarer sind.
> Der Umfang liegt meist unter 20 Webseiten innerhalb eines
> Domainnamens, die Inhalte der Seiten maximal bis ca. 3 "normal"
> beschriebene DIN-A4-Seiten. Meine Arbeitsbedingungen sind also alles
> andere als anspruchsvoll, trotzdem habe ich die meist angebotene
> Honorarerstattung noch nie leisten müssen, da meine Ansagen eintrafen.
Wenn die Bedingungen gut sind, kann auch das gehen, aber ich habe auch
schon einen Fall erlebt, da hatten dynamisch generierte URLs am
schlechten Ranking Mitschuld, und leider waren die nicht umschreibbar.
>>> Mit "sauberen" Methoden, natürlich, ohne dafür Linkfarmen anzulegen etc.
>>> Allerdings geht das meist mit einem Umbau oder einer Neugestaltung einher,
>>> sodass die Preislage den genannten 2k Euro nahe kommt.
>> Das kommt unter bestimmten Umständen durchaus hin, ja. Im genannten Fall
>> waren 2k Euro aber maßlos überzogen.
> Für die Anlage irgendeines Linkgeklingels stimmt das. Bei kompletter
> SEO-gerechter Gestaltung samt Recherche brauchbarer Begriffe,
> Konkurrenzanalyse, redaktioneller Beratung/Betreuung und Ansage der zu
> erreichenden SERP samt Zusage einer anteiligen Erstattung bei nicht
> eingehaltener Ansage sieht es m.E. anders aus, da ist das eher ein
> Kampfpreis ...
ACK! Das kommt dann aber oftmals einem kompletten Neuschreiben der
Seiten gleich.
Grüße,
Alex
Wolfgang Ewert
> Alexander Schestag schrieb:
...
> Es gibt auch preiswertere Anbieter, die saubere Methoden anwenden. Frag
> meine Kunden :)
Hmmm, IMO sollte man sich das Geld für Verzeichnissse oder Datenbanken
der zugehörigen Interessengruppen, halt für den Klüngel, aufsparen, ohne
den jwl. Fa. ein Nichts ist.
Wolfgang
Wolfgang Ewert
...
> Doch. Off-Page-Optimierung ist deutlich mehr, als nur für eingehende
> Links zu sorgen. Dazu gehört die richtige Wahl des Domainnamens und der
> Verzeichnis- und Dateinamen.... Es gibt aber auch einige Dinge,... wie
> ... das "suchmaschinenfreundliche"
> Umschreiben von URLs. Nimm den Fall, daß du ganz furchtbare, dynamisch
> generierte URLs der Form http://www.bla.de/blubb.php?blibb=1&blebb=2
> hast. Google hatte mit sowas lange Probleme (und hat sie wohl teilweise
> noch),
Nö.
Meine Datenbank mit URLs genau dieser Form hat Google sich nahezu
komplett einverleibt (sogar mit allen Wandlungen, die bei den
google-gecacheden Ergebnissen z.T. und vorübergehend zu inhaltsleeren
Seiten führte). Zudem liefere ich die Datenbank-Ergebnisse mit einem aus
der DB generierten Zeitstempel aus, was einige wenige Robots (Slurp, der
Rest geht im Rauschen unter) auch auswerten (aber noch weniger Clients -
zumindest, wenn ich meine eigenen Zugriffe ignoriere :-/).
Yahoo hat meine gestrigen Änderungen heute nacht noch mitgenommen, mal
sehen, wann sie abrufbar sind.
> andere Suchmaschinen haben diese Probleme nach wie vor.
MSN (live.com) tuts auch, Yahoo cached die Inhalte dieser URL-Form
nicht. Yahoo hats nicht vollständig (MSN dagegen hat nachgeholt), das
hatte aber andere, hier diskutierte Gründe.
Abacho.de kommt auch ran; fastbot und exalead habe ich nicht getestet
(Metager-Treffer).
Welche SEs bleiben noch?
Gruß
Wolfgang
Wolfgang Ewert
> Abacho.de kommt auch ran;
1. Ist die Oberfläche von Abacho krank - muss man sich nicht antun.
Schon von daher scheiden sie aus - es soll aber auch Masoristen geben.
2. Haben die sehr eigenwillige Vorstellungen von dem was Treffer sind.
Test:
Evangelische Mittelschule - gesuchte Mittelschul-Seite nicht unter den
38 (von 44 genannten) Treffern.
Evangelische Mittelschule $Ort - keine Treffer
Mittelschule $Ort - keine Treffer
Schule $Ort - viele Treffer mit der Mittelschule-Homepage auf Platz 1:
"evangelische mittelSCHULE $ORT, ... ersatzSCHULE"
Aha, stecken doch die ursprünglichen Suchbegriffe mit im Ergebnis
*grübel*
> fastbot und exalead habe ich nicht getestet
> (Metager-Treffer).
Hmm, Metager listet Abacho-Treffer passend zum Suchstring, nutzen die
eine geheime Abacho-API?
Wolfgang, Abacho zukünftig wieder meidend.
Gustaf Mossakowski
>> Was hat das mit dem Apache-Modul mod_rewrite zu tun? So wie ich das
>> verstehe, ist doch bei »Off-Page-Optimierung« überhaupt kein Zugriff
>> auf den Server, auf dem die Website läuft, nötig.
>
> Doch. Off-Page-Optimierung ist deutlich mehr, als nur für eingehende
> Links zu sorgen. Dazu gehört die richtige Wahl des Domainnamens und der
> Verzeichnis- und Dateinamen.
Ok. Der richtige Domainname, das wäre für mich wieder eine andere
Baustelle, die man auch nachträglich nur schwer ändern kann, zumindest
bei mittleren und kleinen Websites.
> Das kann man natürlich auch bei einem
> Shared-Hosting-Provider beeinflussen, insofern man Unterverzeichnisse
> anlegen darf, was zumindest meiner Erfahrung nach früher nicht überall
> erlaubt war.
Das habe ich schon lange nicht mehr gehört, dass hört sich an wie
letztes Jahrtausend.
> Es gibt aber auch einige Dinge, die über eine .htaccess
> laufen müssen, wie Redirects oder das "suchmaschinenfreundliche"
> Umschreiben von URLs. Nimm den Fall, daß du ganz furchtbare, dynamisch
> generierte URLs der Form http://www.bla.de/blubb.php?blibb=1&blebb=2
> hast.
Es gibt verschiedene Möglichkeiten, bei einem Webserver einen Redirect
zu machen. Beim Apache-Webserver geht das über die httpd.conf oder über
eine .htaccess-Datei. Man kann aber auch mit Perl, PHP oder anderen
Skriptsprachen einen Redirect auf eine andere Seite setzen. Andere
Webserver werden sicher auch andere Mechanismen haben.
Was ich nicht ganz verstehe ist, warum man, wenn man sich keinen
ordentlichen Webspace für zwei, drei Euro leisten kann, überhaupt eine
dynamische Website benötigt. Da wird es billiger sein, die Website
statisch zu erstellen, sei es mit einem Editor oder mit einem offline
laufenden CMS, dessen Output man dann auf den Webserver lädt.
Ich habe auch schon Websites erstellt, die auf billigerem Webspace
liegen, wo kein Zugriff auf mod_rewrite möglich ist. Dort kann man aber
mit "Options +MultiViews" in der Apache-Konfiguration sehr schöne URLs
in der Form /nachrichten/amerika/2007-01-11/ oder so zusammenbauen,
wobei hier im "document root" des Webservers z. B. ein Skript
nachrichten.php liegt, dass die URL parst und den entsprechenden Inhalt
zurückgibt.
> Google hatte mit sowas lange Probleme (und hat sie wohl teilweise
> noch), andere Suchmaschinen haben diese Probleme nach wie vor. Deswegen
> sollte man solche URLs "suchmaschinenfreundlich" umschreiben.
Heutzutage, da Scheußlichkeiten in den URLs Trumpf zu sein scheinen,
kann es sich doch gar keine Suchmaschine mehr leisten, mit Parametern in
URLs Probleme zu haben. Solche URLs werden im schlechtesten Fall
langsamer in den Index aufgenommen. Ob Google und Co. die
URL-Bestandteile jenseits des Domainnamen bewertet, ist meines Wissens
nach zumindest umstritten. Letztlich ist das ja auch ein
»On-Page«-Faktor, also vom Webmaster beeinflußbar, im Gegensatz zu
»Off-Page«, das, so verstehe ich das, ja nicht unmittelbar vom Webmaster
zu beeinflussen ist.
Gute URLs sollten primär »menschenfreundlich«, d. h. lesbar sein und
eine sinnvolle Hierarchie haben, so dass ich als Besucher die Struktur
auch vielfältig nutzen kann (z. B. eine Hierarchie nach oben gehen, auch
wenn das nicht vom Webmaster angeboten wird). Aber das hat nur am Rande
etwas mit Suchmaschinen zu tun.
Viele Grüße
Gustaf
Alexander Schestag
Gustaf Mossakowski wrote:
> Alexander Schestag schrieb:
> Ok. Der richtige Domainname, das wäre für mich wieder eine andere
> Baustelle,
Ist aber Off-Page-Optimierung.
> die man auch nachträglich nur schwer ändern kann, zumindest
> bei mittleren und kleinen Websites.
Man kann schon, allerdings kostet das, und es dauert, bis du deine
Rankings wieder hast.
>> Das kann man natürlich auch bei einem
>> Shared-Hosting-Provider beeinflussen, insofern man Unterverzeichnisse
>> anlegen darf, was zumindest meiner Erfahrung nach früher nicht überall
>> erlaubt war.
> Das habe ich schon lange nicht mehr gehört, dass hört sich an wie
> letztes Jahrtausend.
Letztes Jahrtausend kommt hin. ;-) Das muß Ende der 1990er gewesen sein.
> Es gibt verschiedene Möglichkeiten, bei einem Webserver einen Redirect
> zu machen. Beim Apache-Webserver geht das über die httpd.conf oder über
> eine .htaccess-Datei.
Und auf beides hast du dümmstenfalls keinen Zugriff.
> Man kann aber auch mit Perl, PHP oder anderen
> Skriptsprachen einen Redirect auf eine andere Seite setzen.
Davon ist abzuraten, genauso wie von Redirects via HTML. Vernünftige
Redirects sollten immer über den Webserver laufen.
> Was ich nicht ganz verstehe ist, warum man, wenn man sich keinen
> ordentlichen Webspace für zwei, drei Euro leisten kann, überhaupt eine
> dynamische Website benötigt.
Auch bei teureren Webspaces mit vielen Features hast du kein
mod_rewrite, wenn du Pech hast.
> Ich habe auch schon Websites erstellt, die auf billigerem Webspace
> liegen, wo kein Zugriff auf mod_rewrite möglich ist. Dort kann man aber
> mit "Options +MultiViews" in der Apache-Konfiguration sehr schöne URLs
> in der Form /nachrichten/amerika/2007-01-11/ oder so zusammenbauen,
Wenn das geht, ist das fein.
>> Google hatte mit sowas lange Probleme (und hat sie wohl teilweise
>> noch), andere Suchmaschinen haben diese Probleme nach wie vor. Deswegen
>> sollte man solche URLs "suchmaschinenfreundlich" umschreiben.
> Heutzutage, da Scheußlichkeiten in den URLs Trumpf zu sein scheinen,
> kann es sich doch gar keine Suchmaschine mehr leisten, mit Parametern in
> URLs Probleme zu haben.
Ist aber so. Einer der Gründe ist, daß hinter solchen Seiten mit
URL-Parametern oft ein ganzer Rattenschwanz an Seiten steckt und Spider
sich totspidern.
> Solche URLs werden im schlechtesten Fall
> langsamer in den Index aufgenommen.
Oder gar nicht, wenn der Spider irgendwann keine Lust mehr hat, die
10001. dynamisch generierte Seite zu parsen.
> Ob Google und Co. die URL-Bestandteile jenseits des Domainnamen bewertet,
> ist meines Wissens nach zumindest umstritten. Letztlich ist das ja auch ein
> »On-Page«-Faktor, also vom Webmaster beeinflußbar,
Nicht unbedingt. Bei eigenen Seiten kannst du das mitunter gut steuern.
Aber sobald du Fremdsoftware einsetzt, die solche URLs erzeugt, müßtest
du die Software schon umschreiben. Da ist der Weg über mod_rewrite in
der Regel leichter. Meistens ist das sogar schon in der Software
integriert, wie z. B. bei einigen CMS. Aber der Server muß es halt können.
Grüße,
Alex
Ina Koys
Du redest in Rätseln.
Ina
Niels Braczek
> Wolfgang Ewert schrieb:
>> Hmmm, IMO sollte man sich das Geld für Verzeichnissse oder Datenbanken
>> der zugehörigen Interessengruppen, halt für den Klüngel, aufsparen, ohne
>> den jwl. Fa. ein Nichts ist.
>
> Du redest in Rätseln.
Zu deutsch: "IMO sollte man sich das Geld Backlinks kaufen."
Niels Braczek
> Niels Braczek <nbra...@freenet.de> wrote:
>> Zu deutsch: "IMO sollte man sich das Geld Backlinks kaufen."
> ^
> ... für ...
Muss ich mich deutch noch üben ;-)
> Eine gut gemachte Site mit hinreichendem Content, ausgiebig verlinkt in
> möglichst passenden und vielen kostenlosen Branchenbüchern, Katalogen
> etc., wird sich hoch platzieren.
FullACK. Das entspricht auch meinen Erfahrungen.
Wolfgang Ewert
> Ina Koys schrieb:
> >> Hmmm, IMO sollte man sich das Geld für Verzeichnissse oder Datenbanken
> >> der zugehörigen Interessengruppen, halt für den Klüngel, aufsparen, ohne
> >> den jwl. Fa. ein Nichts ist.
> >
> > Du redest in Rätseln.
>
> Zu deutsch: "IMO sollte man sich das Geld Backlinks kaufen."
Nein, ich meinte nicht Backlinks sondern mehr oder weniger kosten-
pflichtige Einträge in die jeweiligen Verzeichnisse und Datenbanken
(Stichwort: Branchenbuch) der Interessen-verbände, Zünfte und wie sie
alle heißen.
Wolfgang
Wolfgang Ewert
> Ina Koys schrieb:
> >> Hmmm, IMO sollte man sich das Geld für Verzeichnissse oder Datenbanken
> >> der zugehörigen Interessengruppen, halt für den Klüngel, aufsparen, ohne
> >> den jwl. Fa. ein Nichts ist.
> >
> > Du redest in Rätseln.
>
> Zu deutsch: "IMO sollte man sich das Geld Backlinks kaufen."
Nein, ich meinte nicht Backlinks[1] sondern mehr oder weniger kosten-
pflichtige Einträge in die jeweiligen Verzeichnisse und Datenbanken
(Stichwort: Branchenbuch) der Interessen-verbände, Zünfte und wie sie
alle heißen.
[1] Die Backlinks, die ich brauchte, sind z.T. auch durch solche
(allerdings in diesem Falle kostenfreien) DB-Einträge entstanden, indem
die dort bereits existierenden Einträge um den Verweis auf die nun
vorhandene Homepage erweitert wurden. Z.T. sind sie auch durch andere
Interessierte in der Gemeinde (einschl. Gemeinde-Homepage) gesetzt
worden. Im kommerziellen Bereich mag das evtl. wieder anders aussehen.
Wolfgang
Gustaf Mossakowski
>>> Das kann man natürlich auch bei einem Shared-Hosting-Provider
>>> beeinflussen, insofern man Unterverzeichnisse anlegen darf, was
>>> zumindest meiner Erfahrung nach früher nicht überall erlaubt war.
>
>> Das habe ich schon lange nicht mehr gehört, dass hört sich an wie
>> letztes Jahrtausend.
>
> Letztes Jahrtausend kommt hin. ;-) Das muß Ende der 1990er gewesen sein.
Na, das sollte dann ja heute, über sieben Jahre später, ja kein Argument
mehr sein.
>> Man kann aber auch mit Perl, PHP oder anderen
>> Skriptsprachen einen Redirect auf eine andere Seite setzen.
>
> Davon ist abzuraten, genauso wie von Redirects via HTML. Vernünftige
> Redirects sollten immer über den Webserver laufen.
So pauschal muß ich Dir widersprechen. Natürlich ist die Performance von
Redirects in der httpd.conf viel besser, in der .htaccess etwas besser
als in Skripten. Aber deswegen davon abraten? Das ist immer noch besser
als ein 404 Fehler. Und bei der Website mit billigem Webspace, die ja
Diskussionsgrundlage war, wird ein bißchen Performance-Verlust sicher
nicht so schlimm sein.
>> Heutzutage, da Scheußlichkeiten in den URLs Trumpf zu sein scheinen,
>> kann es sich doch gar keine Suchmaschine mehr leisten, mit
>> Parametern in URLs Probleme zu haben.
>
> Ist aber so. Einer der Gründe ist, daß hinter solchen Seiten mit
> URL-Parametern oft ein ganzer Rattenschwanz an Seiten steckt und Spider
> sich totspidern.
Das hat doch nichts mit der URL zu tun. Ich kann auch tausende Seiten
mit URLs ohne Querystring erstellen, an denen sich eine Suchmaschine
totläuft. Wenn sie das überhaupt wird. Google z. B. durchsucht ja auch
nicht bei einer Website sofort alle Seiten bis in die unterste Ebene.
>> Solche URLs werden im schlechtesten Fall
>> langsamer in den Index aufgenommen.
>
> Oder gar nicht, wenn der Spider irgendwann keine Lust mehr hat, die
> 10001. dynamisch generierte Seite zu parsen.
An URLs mit oder ohne Querystring kann man nicht erkennen, dass es sich
um eine dynamisch generierte Seite handelt. Man kann es höchstens
vermuten. Auch eine Site mit Parametern in der URL umfaßt nicht
automatisch 10.000 Seiten, das halte ich für Quatsch.
>> Ob Google und Co. die URL-Bestandteile jenseits des Domainnamen
>> bewertet, ist meines Wissens nach zumindest umstritten. Letztlich
>> ist das ja auch ein »On-Page«-Faktor, also vom Webmaster
>> beeinflußbar,
>
> Nicht unbedingt. Bei eigenen Seiten kannst du das mitunter gut steuern.
> Aber sobald du Fremdsoftware einsetzt, die solche URLs erzeugt, müßtest
> du die Software schon umschreiben. Da ist der Weg über mod_rewrite in
> der Regel leichter. Meistens ist das sogar schon in der Software
> integriert, wie z. B. bei einigen CMS. Aber der Server muß es halt können.
Ja, schlecht geschriebene Software gibt es viel, gerade auf dem
CMS-Markt. Gottseidank muß man sie nicht benutzen. Mich amüsiert es
schon, dass einige kostenlose, populäre CMS damit werben, dass man jetzt
auch »suchmaschinenfreundliche« URLs erstellen kann. Die haben das
Konzept des WWW überhaupt nicht verstanden. Gut lesbare und sinnvoll
organisierte URLs sind das Grundgerüst einer jeden Website, nicht
dekorative Beigabe.
Viele Grüße
Gustaf
Niels Braczek
> Die haben das
> Konzept des WWW überhaupt nicht verstanden. Gut lesbare und sinnvoll
> organisierte URLs sind das Grundgerüst einer jeden Website, nicht
> dekorative Beigabe.
Da hast *du* das Konzept des WWW wohl missverstanden. Dessen
Grundpfeiler sind lediglich[tm] *eindeutige* URLs. Alles andere ist
Zierde. Nützlich und sinnvoll, zugegeben, aber nicht notwendig.
Niels Braczek
> Niels Braczek <nbra...@freenet.de> writes:
>> Da hast *du* das Konzept des WWW wohl missverstanden. Dessen
>> Grundpfeiler sind lediglich[tm] *eindeutige* URLs.
>
> Wann ist ein(e) »URL« denn »eindeutig«?
Ein URL ist dann eindeutig, wenn er auf *genau eine* Ressource zeigt.
> Was wäre ein Beispiel für ein(e)(n) »eindeutige(n)« URL?
> (Bitte möglichst den/die/das konkreten URL angeben.)
>
> Was wäre ein Beispiel für ein(e)(n) nich »eindeutige(n)« URL?
> (Bitte möglichst den/die/das konkreten URL angeben.)
In der Praxis lösen die Webserver eventuelle Konflikte bei mangelnder
Eindeutigkeit auf (vgl. "ambiguous filename"). Daher kann man einen URL
generell als eindeutig ansehen, weil man reproduzierbar auch für den
eigentlich nicht eindeutigen URL dasselbe Ergebnis präsentiert bekommt.
Es ging hier aber um einen völlig anderen Aspekt: Mein Vorredner meinte,
das Konzept des WWW setze *sprechende* URLs voraus. Und das ist schlicht
flasch.
Gustaf Mossakowski
>> Die haben das
>> Konzept des WWW überhaupt nicht verstanden. Gut lesbare und sinnvoll
>> organisierte URLs sind das Grundgerüst einer jeden Website, nicht
>> dekorative Beigabe.
>
> Da hast *du* das Konzept des WWW wohl missverstanden. Dessen
> Grundpfeiler sind lediglich[tm] *eindeutige* URLs. Alles andere ist
> Zierde. Nützlich und sinnvoll, zugegeben, aber nicht notwendig.
Wenn man das WWW allein als ein technisches Phänomen betrachtet, hast du
sicherlich recht. So ist auch die mangelnde Sensibilität bei manchen
Programmierern im Umgang mit URLs zu erklären. Das Netz ist aber vor
allem ein soziales Phänomen. Und da steht, zwischendurch durch die
Kommerzialisierung etwas ins Hintertreffen geraten, vor allem die
Verlinkung im Vordergrund, die aus dem Netz erst ein Netz macht.
Links werden leichter und schneller gesetzt, wenn man die Logik hinter
den URLs erkennt. Von <http://www.google.de/search?q=test> kann ich
schnell <http://www.google.de/search?q=irgendwas> schließen,
h*tp://del.icio.us/for/[username] ist einfach austauschbar. Selbst so
kryptische URLs wie h*tp://www.youtube.com/watch?v=[12stelliger Code]
sind noch verständlich, da kurz.
URLs wie
<http://h20247.www2.hp.com/publicsector/cache/424075-0-0-15-150.html>,
<http://www.an-online.de/sixcms/detail.php?template=an_detail&id=237781&_
wo=Sport:Nachrichten&_link=&skip=&_g=Tour-droht-Fahrt-ins-Ungewisse>
oder <http://typo3.com/Leistungsmerkmale.1243.0.html?&L=2> sind dagegen
weder merkbar und schaffen teilweise noch Probleme, z. B. wegen ihrer
sinnlosen Länge.
Das Domain Name System (DNS) ist auch ein Beispiel. Auch nicht
notwendig, aber ohne das DNS wäre das Internet nie so erfolgreich
geworden, wie es ist. Oder tippst du in den Browser <http://3512041875/>
ein, wenn du Google erreichen willst? (Funktioniert mittlerweile leider
nicht mehr in allen Browsern, Opera macht's aber noch.)
| What, design a URI? I have to design URIs? Yes, you have to think
| about it.
<http://www.w3.org/Provider/Style/URI.html>
Ich denke nicht, dass ich das Konzept mißverstanden habe.
Viele Grüße
Gustaf
Christoph Schneegans
> Ein URL ist dann eindeutig, wenn er auf *genau eine* Ressource zeigt.
Das tut eine URL immer, sie kann überhaupt nicht anders.
> In der Praxis lösen die Webserver eventuelle Konflikte bei mangelnder
> Eindeutigkeit auf (vgl. "ambiguous filename"). Daher kann man einen URL
> generell als eindeutig ansehen, weil man reproduzierbar auch für den
> eigentlich nicht eindeutigen URL dasselbe Ergebnis präsentiert bekommt.
Das verstehe ich nicht. Meinst du den Fall, daß mehr als eine URL auf eine
Ressource verweist?
--
<http://schneegans.de/web/kanonische-adressen/> · URLs richtig verwenden
Christoph Schneegans
> <http://www.w3.org/Provider/Style/URI.html>
Ausgerechnet dieser Klassiker propagiert nun aber bedeutungslose URLs und
verfolgt damit ein einziges Ziel, nämlich deren Persistenz, und zwar um
jeden Preis. Ich halte dieses Vorgehen für blödsinnig, und ich würde auch
niemals auf die Idee kommen, den "report of the minutes of a meeting of
W3C chair people" unter "http://www.w3.org/1998/12/01/chairs" abzulegen.
Alexander Schestag
> Alexander Schestag schrieb:
>>> Man kann aber auch mit Perl, PHP oder anderen
>>> Skriptsprachen einen Redirect auf eine andere Seite setzen.
>> Davon ist abzuraten, genauso wie von Redirects via HTML. Vernünftige
>> Redirects sollten immer über den Webserver laufen.
> So pauschal muß ich Dir widersprechen. Natürlich ist die Performance von
> Redirects in der httpd.conf viel besser, in der .htaccess etwas besser
> als in Skripten. Aber deswegen davon abraten?
Es geht nicht um die Performance, sondern um die
Suchmaschinentauglichkeit. Redirects in HTML und JavaScript sind dafür
völlig unbrauchbar. Allerdings muß ich mich korrigieren. Serverseitige
Weiterleitungen aller Art, auch die von dir genannten, sind ungefähr
gleichwertig. Nur von clientseitigen ist abzuraten.
> Das ist immer noch besser als ein 404 Fehler. Und bei der Website mit
> billigem Webspace, die ja Diskussionsgrundlage war, wird ein bißchen
> Performance-Verlust sicher nicht so schlimm sein.
Wenn der Performance-Verlust darin besteht, daß eine Seite wegen eines
Redirects aus Suchmaschinen fliegt, ist das so ziemlich das Schlimmste,
was dir passieren kann.
>> Ist aber so. Einer der Gründe ist, daß hinter solchen Seiten mit
>> URL-Parametern oft ein ganzer Rattenschwanz an Seiten steckt und Spider
>> sich totspidern.
> Das hat doch nichts mit der URL zu tun.
Doch.
> Ich kann auch tausende Seiten mit URLs ohne Querystring erstellen, an
> denen sich eine Suchmaschine totläuft.
Die sind aber nicht *gleich*, dynamisch generierte URLs sind im oben
geschilderten Fall dagegen völlig *gleich* (bis auf die Parameter
natürlich). Das ist der Punkt.
> Wenn sie das überhaupt wird. Google z. B. durchsucht ja auch
> nicht bei einer Website sofort alle Seiten bis in die unterste Ebene.
Und wenn schon eine eine von der index-Seite aus verlinkte Seite
massenweise dynamische Seiten mit Parametern produziert?
>>> Solche URLs werden im schlechtesten Fall
>>> langsamer in den Index aufgenommen.
>> Oder gar nicht, wenn der Spider irgendwann keine Lust mehr hat, die
>> 10001. dynamisch generierte Seite zu parsen.
> An URLs mit oder ohne Querystring kann man nicht erkennen, dass es sich
> um eine dynamisch generierte Seite handelt. Man kann es höchstens
> vermuten.
Aber in 99.99% der Fälle, denn einer Webseite aus reinem HTML
URL-Parameter mitzugeben, ist sinnfrei, weil HTML selber damit nichts
anfangen kann. D. h. es braucht eine Script-Sprache, die die Werte der
URL-Parameter auswertet und mit deren Hilfe die Seite, d. h. das fertige
HTML, dynamisch generiert.
> Auch eine Site mit Parametern in der URL umfaßt nicht
> automatisch 10.000 Seiten, das halte ich für Quatsch.
Das habe ich auch nirgends behauptet. Aber sie KANN. Und dann hast du
ein Problem.
> Ja, schlecht geschriebene Software gibt es viel, gerade auf dem
> CMS-Markt. Gottseidank muß man sie nicht benutzen. Mich amüsiert es
> schon, dass einige kostenlose, populäre CMS damit werben, dass man jetzt
> auch »suchmaschinenfreundliche« URLs erstellen kann. Die haben das
> Konzept des WWW überhaupt nicht verstanden. Gut lesbare und sinnvoll
> organisierte URLs sind das Grundgerüst einer jeden Website, nicht
> dekorative Beigabe.
Das sehe ich anders. Grade bei CMS sind URLs mit Parametern oft nicht zu
vermeiden. Daher ist der Vorwurf, die hätten das Konzept des WWW nicht
verstanden, Unsinn. Das sind Open Source Projekte, die begrenzte
Ressourcen haben, und man kann solche Dinge oft erst nach und nach
umsetzen. Ich denke, daß die Leute, die solche CMS schreiben, das
Konzept des WWW besser verstanden haben, als die Mehrheit der Leute, die
im Web unterwegs sind.
Alex
Niels Braczek
> Niels Braczek schrieb:
>
>> Ein URL ist dann eindeutig, wenn er auf *genau eine* Ressource zeigt.
>
> Das tut eine URL immer, sie kann überhaupt nicht anders.
Das ist der Punkt.
>> In der Praxis lösen die Webserver eventuelle Konflikte bei mangelnder
>> Eindeutigkeit auf (vgl. "ambiguous filename"). Daher kann man einen URL
>> generell als eindeutig ansehen, weil man reproduzierbar auch für den
>> eigentlich nicht eindeutigen URL dasselbe Ergebnis präsentiert bekommt.
>
> Das verstehe ich nicht. Meinst du den Fall, daß mehr als eine URL auf eine
> Ressource verweist?
Nein, umgekehrt: dass ein URL auf mehrere Ressourcen verweist.
Manche Server sind so konfiguriert, dass sie auf einen URL wie
"example.com/index" mit einer Liste von Dateien antworten, zB.
"index.html", "index.php", "index.txt". Ursprünglich ist der URL daher
etwas in der Art von mehrdeutig (genau genommen aber doch eindeutig,
nämlich falsch; die angeforderte Ressource existiert ja nicht).
Niels Braczek
> Niels Braczek schrieb:
> Links werden leichter und schneller gesetzt, wenn man die Logik hinter
> den URLs erkennt.
Das sehe ich auch so. Daher gehören sprechende URLs nicht zum Konzept
des WWW, sondern zur (SE)Optimierung. Sie sind ein Bonus, keine
Notwendigkeit.
Wolfgang Ewert
> Niels Braczek schrieb:
>
> > Ein URL ist dann eindeutig, wenn er auf *genau eine* Ressource zeigt.
>
> Das tut eine URL immer, sie kann überhaupt nicht anders.
Aber nur zu einem Zeitpunkt (zum nächsten Zeitpunkt: Error 404). Für die
Nutzung über SEs hinweg kommt die Notwendigkeit der Persistenz
(zumindest im Bereich von SE-Intervallen) hinzu.
> Das verstehe ich nicht. Meinst du den Fall, daß mehr als eine URL auf eine
> Ressource verweist?
Alle die mit verschiedenen ...&sid=12345678...
Wolfgang
Gustaf Mossakowski
>> Das ist immer noch besser als ein 404 Fehler. Und bei der Website mit
>> billigem Webspace, die ja Diskussionsgrundlage war, wird ein bißchen
>> Performance-Verlust sicher nicht so schlimm sein.
>
> Wenn der Performance-Verlust darin besteht, daß eine Seite wegen eines
> Redirects aus Suchmaschinen fliegt, ist das so ziemlich das Schlimmste,
> was dir passieren kann.
Mit schlechterer Performance meine ich die höhere Rechenzeit für einen
Redirect aus einem Skript gegenüber einem in der Serverkonfiguration.
Ein 404 bedeutet langfristig fast immer, dass eine Seite aus dem Index
fliegt. Ein (sehr sehr) langsamer Server, der bei einem einmaligen
Suchmaschinenbesuch eine Anfrage nicht rechtzeitig beantwortet bedeutet
dagegen nur höchst selten, dass die Seite aus dem Index fliegt.
>> Ich kann auch tausende Seiten mit URLs ohne Querystring erstellen, an
>> denen sich eine Suchmaschine totläuft.
>
> Die sind aber nicht *gleich*, dynamisch generierte URLs sind im oben
> geschilderten Fall dagegen völlig *gleich* (bis auf die Parameter
> natürlich). Das ist der Punkt.
Was bedeutet für dich »gleich«? Du willst doch nicht sagen,
<http://www.google.de/search?q=wetter> und
<http://www.google.de/search?q=regen> sind gleiche URLs, da sie sich ja
nur durch den Parameter unterscheiden. Das sind unterschiedliche URLs.
>> Wenn sie das überhaupt wird. Google z. B. durchsucht ja auch
>> nicht bei einer Website sofort alle Seiten bis in die unterste Ebene.
>
> Und wenn schon eine eine von der index-Seite aus verlinkte Seite
> massenweise dynamische Seiten mit Parametern produziert?
Warum sollte man? So ganz kann ich dir hier nicht folgen. Wenn ich auf
example.com fünftausend Links auf Unterseiten setze, ist es egal, ob
diese Parameter haben oder nicht. Google und Co. werden, wenn die Site
frisch im Netz ist, keinesfalls sofort allen 5.000 Links folgen. Später
nur, wenn die Suchmaschine die Seite als wichtig erachtet.
> Aber in 99.99% der Fälle, denn einer Webseite aus reinem HTML
> URL-Parameter mitzugeben, ist sinnfrei, weil HTML selber damit nichts
> anfangen kann. D. h. es braucht eine Script-Sprache, die die Werte der
> URL-Parameter auswertet und mit deren Hilfe die Seite, d. h. das fertige
> HTML, dynamisch generiert.
Kann man z. B. mit JavaScript machen. Ich bin mir nicht sicher,
vielleicht kann man die Parameter auch mit SSI auswerten?
>> Auch eine Site mit Parametern in der URL umfaßt nicht
>> automatisch 10.000 Seiten, das halte ich für Quatsch.
>
> Das habe ich auch nirgends behauptet. Aber sie KANN. Und dann hast du
> ein Problem.
Siehe oben. Das trifft genauso auf eine Site ohne URLs mit Parametern zu.
> Das sehe ich anders. Grade bei CMS sind URLs mit Parametern oft nicht zu
> vermeiden.
Ich habe gar nichts gegen Parameter, bei Suchabfragen z. B. finde ich
Ergebnisseiten ohne Parameter seltsam. Ob ein CMS URLs mit Parametern
braucht, ist eine Frage der Konzeption. Man kann auch gut auf sie
verzichten.
> Daher ist der Vorwurf, die hätten das Konzept des WWW nicht
> verstanden, Unsinn. Das sind Open Source Projekte, die begrenzte
> Ressourcen haben, und man kann solche Dinge oft erst nach und nach
> umsetzen. Ich denke, daß die Leute, die solche CMS schreiben, das
> Konzept des WWW besser verstanden haben, als die Mehrheit der Leute, die
> im Web unterwegs sind.
Ach, da muß man differenzieren. Z. B. finde ich das Backend von Joomla!
sehr schick und könnte es sicherlich nicht so schnell ähnlich nachbauen.
Aber die Verschachtelung mit Tabellen und Divs in den Templates (habe
das System nur einmal in Version 1.08 benutzt, das wird hoffentlich
jetzt besser sein) und das daher nur schlecht mögliche Arbeiten mit der
Kaskade des CSS, das fand ich sehr unpraktisch zu benutzen. Ich denke
nicht, dass es ein Problem der zu geringen Ressourcen auf
Entwicklerseite ist, dass ein CMS keine vernünftige, sprechende
URL-Struktur unterstützt. Es ist eine Frage der Prioritäten.
Viele Grüße
Gustaf
Gustaf Mossakowski
>> <http://www.w3.org/Provider/Style/URI.html>
>
> Ausgerechnet dieser Klassiker propagiert nun aber bedeutungslose URLs und
> verfolgt damit ein einziges Ziel, nämlich deren Persistenz, und zwar um
> jeden Preis. Ich halte dieses Vorgehen für blödsinnig [...]
Warum? Was gefällt dir nicht? Die Persistenz oder dass das Ziel um jeden
Preis erreicht werden soll?
> [...], und ich würde auch
> niemals auf die Idee kommen, den "report of the minutes of a meeting of
> W3C chair people" unter "http://www.w3.org/1998/12/01/chairs" abzulegen.
Naja, Veranstaltungen unter deren Datum abzulegen, ist ja nun kein
schlechtes Konzept, ganz im Gegenteil, das ist doch sogar ein sehr weit
verbreitetes Konzept. Aber letztlich hat jeder Mensch natürlich seine
eigenen Ordnungsprinzipien, wie er oder sie etwas ablegt.
Viele Grüße
Gustaf
Gustaf Mossakowski
> <http://typo3.com/Leistungsmerkmale.1243.0.html?&L=2>
>
> Um auf das Typo3-Beispiel näher enzugehen: Der URL schöpft nicht das
> Potenzial des CMS aus, dann würde er schlicht
> <http://typo3.com/Leistungsmerkmale.html> lauten (was jetzt einfach auf
> die Startseite der Domain führt).
>
> Wenn du "L=2" austauscht gegen "L=1", wird das Funktionsprinzip klarer,
> aber das sollte man von unbedarfteren Nutzern eher nicht erwarten.
Habe ich probiert, war neugierig, wofür das da war und da hatte ich es
auch gesehen. Deutlich weit verbreiteter ist da ja, z. B.
example.org/en/leistungsmerkmale und example.org/de/leistungsmerkmale
oder ähnliches als URL zu verwenden. Das ist zwar auch nicht für jeden
klar, was »en« respektive »de« bedeutet, aber doch schon deutlich mehr
als L=1 und L=2.
> [... Interessantes über Typo3]
> Es ist besser, sprechende URLs zu bieten, aber unterschätze nicht den
> Aufwand, das tauglich zu implementieren. Auch bei umfänglichen Sites
> darf schließlich kein URL doppelt auftauchen, was bei Verwendung der
> Seitenüberschrift oder eines Titels schnell passieren kann.
Natürlich ist das etwas Aufwand, aber das kann ja eine Datenbank, die
häufig hinter einem CMS steht, bei der Eingabe der Inhalte prüfen. Ich
denke aber nicht, dass es viel Aufwand ist. Wenn man von vornherein URLs
die notwendige Bedeutung zukommen lässt, ist es kein sonderlich großer
Aufwand. Ich kann nachvollziehen, dass es sehr schwer ist, bei
bestehenden Content Management Systemen nachträglich sogenannte
»suchmaschinenfreundliche« URLs auf die Systemlogik aufzusetzen.
> Zudem kamen
> erst die Skriptsprachen, danach der Google- und Suchmaschinen-Hype und
> damit das Bewusstsein, dass ein Dokument erst durch die Auffindbarkeit,
> also Referenzierung in SEs erfolgreich wird ...
Ja, cgi-bin/ war auch schlimm, das stimmt. Aber eigentlich waren doch
zuerst die statischen Seiten, dann wurden einzelne Bereiche einer
Website mit Skripten aufpoliert (Kontaktformulare, Terminkalender etc.)
und irgendwann stieg man dann auf ein CMS um. Bei einzelnen Projekten
habe ich die URLs seit Beginn beibehalten. Das geht natürlich nur, wenn
ein CMS einem nicht eine fremde URL-Struktur aufzwingt.
Ich denke, es ist heute gar nicht mehr so wesentlich, für Suchmaschinen
die URLs umzustricken (eher für die Besucher), da mittlerweile alle
führenden Suchmaschinen keine Probleme mit Parametern in der URL haben.
Ob die Stichwörter in der URL, abseits des Domainnamens, viel für die
Platzierung in den Suchergebnissen bringt, ist ja auch zweifelhaft. Ich
lasse mich hier aber gerne vom Gegenteil überzeugen. Das einzige, was
ich in der Richtung kenne, ist Felix Wiemanns Experiment mit Parametern
(<http://groups.google.de/group/de.comm.infosystems.suchmaschinen/browse_
thread/thread/c7cde8944a5e3291/e7f4a7cbda1ca9d0> oder
<news:87y8n95...@news2.ososo.de>)
Viele Grüße
Fustaf
Gustaf Mossakowski
>> Links werden leichter und schneller gesetzt, wenn man die Logik
>> hinter den URLs erkennt.
>
> Das sehe ich auch so. Daher gehören sprechende URLs nicht zum Konzept
> des WWW, sondern zur (SE)Optimierung. Sie sind ein Bonus, keine
> Notwendigkeit.
Na, dann sind wir ja zumindest grundsätzlich einer Meinung (sie sind
gut), nur in der Bewertung der Wichtigkeit nicht. Aber da werden wir
sicher auch nicht einer Meinung werden ;-)
Viele Grüße
Gustaf
Niels Braczek
Das schließe ich nach wie vor nicht aus ;-)
Ich stelle hier wirklich nur die Notwendigkeit in Abrede. Für die
Akzeptanz bei den Nutzern und den SEs sind sprechende URLs von Vorteil,
also sind sie wichtig. Allerdings in Bezug auf den Content nachrangig.
Niels Braczek
> Alexander Schestag schrieb:
>
>> Daher ist der Vorwurf, die hätten das Konzept des WWW nicht
>> verstanden, Unsinn. Das sind Open Source Projekte, die begrenzte
>> Ressourcen haben, und man kann solche Dinge oft erst nach und nach
>> umsetzen. Ich denke, daß die Leute, die solche CMS schreiben, das
>> Konzept des WWW besser verstanden haben, als die Mehrheit der Leute, die
>> im Web unterwegs sind.
>
> Ach, da muß man differenzieren. Z. B. finde ich das Backend von Joomla!
> sehr schick und könnte es sicherlich nicht so schnell ähnlich nachbauen.
> Aber die Verschachtelung mit Tabellen und Divs in den Templates (habe
> das System nur einmal in Version 1.08 benutzt, das wird hoffentlich
> jetzt besser sein) und das daher nur schlecht mögliche Arbeiten mit der
> Kaskade des CSS, das fand ich sehr unpraktisch zu benutzen. Ich denke
> nicht, dass es ein Problem der zu geringen Ressourcen auf
> Entwicklerseite ist, dass ein CMS keine vernünftige, sprechende
> URL-Struktur unterstützt. Es ist eine Frage der Prioritäten.
Das in Joomla!1.0.x produzierte HTML ist vielfach suboptimal; das ist
ein Mambo-Erbe, mit dem wir sehr unglücklich sind. Joomla!1.5 räumt
damit vollkommen auf, weil diese Dinge (die uU. von Komponenten
mitgebracht werden) dort von Templates komplett geändert werden können.
Das URL-Konzept ist in 1.0.x Anwender-Verantwortung. Es gibt eine Reihe
von Komponenten, die sprechende URLs ermöglichen. Man muss sich nur für
eine entscheiden.
Alexander Schestag
Gustaf Mossakowski wrote:
> Alexander Schestag schrieb:
>>> Ich kann auch tausende Seiten mit URLs ohne Querystring erstellen, an
>>> denen sich eine Suchmaschine totläuft.
>> Die sind aber nicht *gleich*, dynamisch generierte URLs sind im oben
>> geschilderten Fall dagegen völlig *gleich* (bis auf die Parameter
>> natürlich). Das ist der Punkt.
> Was bedeutet für dich »gleich«? Du willst doch nicht sagen,
> <http://www.google.de/search?q=wetter> und
> <http://www.google.de/search?q=regen> sind gleiche URLs, da sie sich ja
> nur durch den Parameter unterscheiden. Das sind unterschiedliche URLs.
Das sind bis auf die Parameter gleiche URLs. Die Parameter zähle ich
nicht zum URL dazu. Das kann man begründen. Zitat Wikipedia aus dem
Artikel "URL":
"URLs identifizieren eine Ressource über ihren primären
Zugriffsmechanismus (häufig oder ftp) und den Ort (engl. location) der
Ressource in Computernetzwerken an"
Parameter gehören also streng genommen *nicht* zum URL dazu. Ergo sind
deine beiden URLs *gleich*.
>>> Wenn sie das überhaupt wird. Google z. B. durchsucht ja auch
>>> nicht bei einer Website sofort alle Seiten bis in die unterste Ebene.
>> Und wenn schon eine eine von der index-Seite aus verlinkte Seite
>> massenweise dynamische Seiten mit Parametern produziert?
> Warum sollte man?
Sowas gibt es durchaus.
> So ganz kann ich dir hier nicht folgen. Wenn ich auf
> example.com fünftausend Links auf Unterseiten setze, ist es egal, ob
> diese Parameter haben oder nicht. Google und Co. werden, wenn die Site
> frisch im Netz ist, keinesfalls sofort allen 5.000 Links folgen. Später
> nur, wenn die Suchmaschine die Seite als wichtig erachtet.
Das ist richtig. Aber sie werden ihnen eher folgen als 5.000 *gleichen*
URLs.
>> Aber in 99.99% der Fälle, denn einer Webseite aus reinem HTML
>> URL-Parameter mitzugeben, ist sinnfrei, weil HTML selber damit nichts
>> anfangen kann. D. h. es braucht eine Script-Sprache, die die Werte der
>> URL-Parameter auswertet und mit deren Hilfe die Seite, d. h. das fertige
>> HTML, dynamisch generiert.
> Kann man z. B. mit JavaScript machen.
Ja und? Auch dann ist die Seite in den allermeisten Fällen dynamisch
generiert, nur halt clientseitig. "Dynamisch generiert" heißt m. E.
nicht, daß die Technologie dafür serverseitig sein muß. Das geht auch
clientseitig. Einige Autoren unterscheiden die serverseitige Generierung
dynamischer Webseiten zwar von der clientseitigen mit JavaScript, aber
das wird auch genauso oft im gleichen Atemzug genannt. Google mal nach
"dynamische Webseiten mit JavaScript", da findest du massenweise Tutorials.
> Ich bin mir nicht sicher, vielleicht kann man die Parameter auch mit SSI auswerten?
Auch das wäre egal.
>>> Auch eine Site mit Parametern in der URL umfaßt nicht
>>> automatisch 10.000 Seiten, das halte ich für Quatsch.
>> Das habe ich auch nirgends behauptet. Aber sie KANN. Und dann hast du
>> ein Problem.
> Siehe oben. Das trifft genauso auf eine Site ohne URLs mit Parametern zu.
Nein, denke ich nicht.
>> Das sehe ich anders. Grade bei CMS sind URLs mit Parametern oft nicht zu
>> vermeiden.
> Ich habe gar nichts gegen Parameter,
Ich auch nicht - nix Wirksames. ;-) Nein, im Ernst, ich versuche, wo
immer es geht, URL-Parameter zu vermeiden, schon alleine, weil sie im
Zweifelsfalle Sicherheitsprobleme bereiten können. Manchmal geht es aber
sinnvollerweise nicht ohne.
> bei Suchabfragen z. B. finde ich Ergebnisseiten ohne Parameter seltsam. Ob ein
> CMS URLs mit Parametern braucht, ist eine Frage der Konzeption. Man kann auch
> gut auf sie verzichten.
Darüber kann man sicher streiten.
>> Daher ist der Vorwurf, die hätten das Konzept des WWW nicht
>> verstanden, Unsinn. Das sind Open Source Projekte, die begrenzte
>> Ressourcen haben, und man kann solche Dinge oft erst nach und nach
>> umsetzen. Ich denke, daß die Leute, die solche CMS schreiben, das
>> Konzept des WWW besser verstanden haben, als die Mehrheit der Leute, die
>> im Web unterwegs sind.
> Ich denke nicht, dass es ein Problem der zu geringen Ressourcen auf
> Entwicklerseite ist, dass ein CMS keine vernünftige, sprechende
> URL-Struktur unterstützt. Es ist eine Frage der Prioritäten.
Ohne Frage. Aber wenn andere Prioritäten gesetzt werden, ist es wieder
eine Ressourcenfrage *g*
Grüße,
Alex
Gustaf Mossakowski
>> Was bedeutet für dich »gleich«? Du willst doch nicht sagen,
>> <http://www.google.de/search?q=wetter> und
>> <http://www.google.de/search?q=regen> sind gleiche URLs, da sie sich
>> ja nur durch den Parameter unterscheiden. Das sind unterschiedliche
>> URLs.
>
> Das sind bis auf die Parameter gleiche URLs. Die Parameter zähle ich
> nicht zum URL dazu. Das kann man begründen. Zitat Wikipedia aus dem
> Artikel "URL":
>
> "URLs identifizieren eine Ressource über ihren primären
> Zugriffsmechanismus (häufig oder ftp) und den Ort (engl. location) der
> Ressource in Computernetzwerken an"
>
> Parameter gehören also streng genommen *nicht* zum URL dazu. Ergo sind
> deine beiden URLs *gleich*.
Eine sehr eigenwillige Definition. Es gibt auch einen RFC zu URLs,
<http://www.ietf.org/rfc/rfc1738.txt>, der sagt unter Punkt 3.3:
| An HTTP URL takes the form:
| http://<host>:<port>/<path>?<searchpart>
Auch in der neueren <http://tools.ietf.org/html/rfc3986> findet sich
nichts Anderslautendes. Dem Wikipedia-Artikel unter
<http://de.wikipedia.org/wiki/URL> kann ich auch nichts entnehmen, das
deiner Auffassung entspricht.
>> [hierarchisch oberste Seite einer Website verlinkt massenweise
>> Unterseiten]
>
> Sowas gibt es durchaus.
Also, ich erkenne in deiner Argumentation immer noch keine Unterstützung
für deine ursprünglich geäußerte These:
| Ist aber so. Einer der Gründe ist, daß hinter solchen Seiten mit
| URL-Parametern oft ein ganzer Rattenschwanz an Seiten steckt und
| Spider sich totspidern.
Das kann man mit Parametern machen, ohne Parameter, sinnvoll ist beides
nicht, zu Tode suchen wird sich keine Suchmaschine, da solche Seiten
höchstwahrscheinlich von den Suchmaschinen nicht als wichtig erachtet
werden (kommt natürlich auf den Inhalt an, es gibt sicher einzelne
sinnvolle Szenarien, in denen von einer Webseite tausende Links auf
andere Seiten erfolgen müssen) und daher die Links über einer gewissen
Zahl nicht mehr verfolgt werden.
> [...] Aber sie werden ihnen eher folgen als 5.000 *gleichen* URLs.
Wie oben geschrieben, URLs mit unterschiedlichen Parametern aber
gleichem Schema, Domainnamen und Pfad sind eben nicht gleich.
>>> Aber in 99.99% der Fälle, denn einer Webseite aus reinem HTML
>>> URL-Parameter mitzugeben, ist sinnfrei, weil HTML selber damit
>>> nichts anfangen kann.
Ok. Nach nochmaligem Lesen stimme ich dir zu, reines HTML kann mit den
Parametern nichts anfangen. SSI und JavaScript sind ja kein HTML.
> Ich auch nicht - nix Wirksames. ;-) Nein, im Ernst, ich versuche, wo
> immer es geht, URL-Parameter zu vermeiden, schon alleine, weil sie im
> Zweifelsfalle Sicherheitsprobleme bereiten können. Manchmal geht es aber
> sinnvollerweise nicht ohne.
Da helfen wohl nur statische Webseiten. Wenn du die URL irgendwie
interpretierst, sei es durch ein Skript oder mod_rewrite, hast du, egal
ob Parameter oder nicht, immer Sicherheitsprobleme.
>> Ich denke nicht, dass es ein Problem der zu geringen Ressourcen auf
>> Entwicklerseite ist, dass ein CMS keine vernünftige, sprechende
>> URL-Struktur unterstützt. Es ist eine Frage der Prioritäten.
>
> Ohne Frage. Aber wenn andere Prioritäten gesetzt werden, ist es wieder
> eine Ressourcenfrage *g*
Ja, dann wird letztlich alles, was nicht getan wird, aus Mangel an
Ressourcen nicht getan ... Fragt sich, ob »Ressourcenmangel« dann
überhaupt noch eine Aussagekraft hat ;-)
Viele Grüße
Gustaf
Gustaf Mossakowski
> [Gehören sprechende URLs zum Konzept des WWW oder nicht]
>> Na, dann sind wir ja zumindest grundsätzlich einer Meinung (sie sind
>> gut), nur in der Bewertung der Wichtigkeit nicht. Aber da werden wir
>> sicher auch nicht einer Meinung werden ;-)
>
> Das schließe ich nach wie vor nicht aus ;-)
Oh. Na, dann versuche ich es doch nochmal!
> Ich stelle hier wirklich nur die Notwendigkeit in Abrede. Für die
> Akzeptanz bei den Nutzern und den SEs sind sprechende URLs von Vorteil,
> also sind sie wichtig. Allerdings in Bezug auf den Content nachrangig.
Sicher ist der Inhalt das Wichtigste. Sprechende URLs zeigen aber auch
eine Hierarchisierung des Contents, dafür sind in den URLs ja extra die
Schrägstriche vorgesehen worden. Eine Hierarchisierung widerspricht
natürlich auf den ersten Blick dem Netzgedanken, auf den zweiten ergänzt
sie ihn aber wunderbar.
Ich tendiere leicht zur Unordnung. Daher brauche ich Strukturen. Mal ein
Beispiel, wie eine gute URL den Inhalt leichter erschließbar macht:
<http://www.dem2004.de/turnier/u10/spieler/1.html>
Hier könnte man noch zusätzlich eine Brotkrumen-Navigation erstellen,
die einem alle Hierarchien anbietet, also /turnier/ (Alle Turniere),
/turnier/u10/ (Turnier Altersklasse U10), /turnier/u10/spieler/ (Alle
Spieler in der Altersklasse U10), die fehlt leider. Das wäre ein
zusätzlicher Nutzen, der jetzt aber schon mit Browsern wie iCab oder der
Erweiterung LinkToolbar (heißt jetzt Link Widgets, glaube ich) für
Firefox möglich ist. Dort kann ich auch ohne Brotkrumen eine
Hierarchiestufe nach oben gehen.
Ausgehend von dieser URL kann ich auch ähnliche Links raten, auch wenn
diese nicht direkt von der Seite verlinkt sind. Unter 2.html befindet
sich z. B. Spieler 2 der Setzliste, unter 3.html Spieler 3 usw. (über
Link Widgets ebenfalls einfach blätterbar). Ich kann u10 gegen u18
austauschen (wenn ich die Altersklassen kenne) und so schnell zu den
Ergebnissen dort kommen.
Für mich als Autor der Website ist es einfacher, die Website zu
erweitern, wenn ich erstmal die Struktur habe. Beispielsweise kam später
eine neue Altersklasse hinzu, die dann genau in die vorhandene
URL-Struktur reinpasste.
Sicherlich sind in der vorliegenden Umsetzung noch ein paar Fehler drin,
z. B. leitet <http://www.dem2004.de/turnier/u18> nicht auf die Seite mit
abschließendem Schrägstrich um und einige Seiten geben auch noch keine
korrekten 404-Fehlermeldungen aus. Das sind aber nur zwei oder drei
Zeilen Code, die hinzugefügt werden müssten.
Sicher, heute gibt es vielfache Möglichkeiten, Lesezeichen zu speichern.
Ich gebe trotzdem immer wieder URLs per Hand in den Browser ein und ich
kenne auch viele andere, die das tun. Wenn die URLs gut lesbar sind,
kann man auch direkt über die URL im Netz navigieren und muß sich nicht
ausschließlich auf die Wege verlassen, die der Webmaster vorsieht. Es
gibt ja viele Wege, wie man Inhalte organisiert, und so biete ich dem
Besucher verschiedene Varianten an. Auf vielen Websites ist das gar
nicht erwünscht, das weiß ich auch, da wird man mit der obersten Seite
einer Website zwangsbeglückt. Grausig.
Ein anderer Vorteil ist, dass ich anhand der URL direkt sehen kann, wo
ich mich befinde.
<http://www.fussballdaten.de/vereine/werderbremen/2008/spiele/> ist eine
klare Aussage, auch wenn ich die Website nie gesehen habe. URL-Konzepte
wie
<https://www.portal-banking.de/wps/portal/!ut/p/.scr/Login?view=net&blz=2
0090500> (das ist leider die Startseite einer Online-Banking-Seite, hier
kann man noch nicht mal den Namen der Bank erkennen, lediglich die
Bankleitzahl, aber da ist eh noch einiges mehr kaputt) oder
<http://www.tchibo.de/is-bin/INTERSHOP.enfinity/eCS/Store/de/-/EUR/TdTchB
rowseCatalog-Start?CategoryName=kaffee&source=NAVI>
(tchibo.de/shop/kaffee) oder
<http://www.mumbaimart.com/component/option,com_events/Itemid,127/>
(mumbaimart.com/events/2007/07/07/ oder mumbaimart.com/events) oder
<http://www.mumbaimart.com/content/category/7/51/148/>
(mumbaimart.com/videos) sagen mir überhaupt nix, da fände ich die in
Klammern gesetzen Alternativen deutlich netter. Man muß sich ja als
Anwender auch überlegen, worauf man klickt, z. B. auch in E-Mails.
Wieso eine Bank-Website nicht den Namen der Bank trägt, erschließt sich
mir überhaupt nicht.
Was ich damit sagen will: sprechende URLs tragen zur Orientierung bei,
sie können Vertrauen in den Anbieter schaffen und erlauben vielfältige
Wege durch eine Website. Auf Anbieterseite erlauben sie eine klare
Strukturierung des Angebots und können auch die Programmierung von
dynamischen Websites erleichtern. Für mich sind das viele Gründe, die
für mich verdeutlichen, dass URLs das Grundgerüst einer jeden Website
zumindest sein sollten, auch wenn das nicht überall so ist. Rein von der
technischen Seite hast du Recht, technisch notwendig sind die nicht.
Sorry, falls es zu lang geworden ist.
Viele Grüße
Gustaf
Wolfgang Ewert
> Gustaf Mossakowski wrote:
> >> Die sind aber nicht *gleich*, dynamisch generierte URLs sind im oben
> >> geschilderten Fall dagegen völlig *gleich* (bis auf die Parameter
> >> natürlich). Das ist der Punkt.
SEs (namentlich Google) unterscheiden nach dem Inhalt.
> > Was bedeutet für dich »gleich«? Du willst doch nicht sagen,
> > <http://www.google.de/search?q=wetter> und
> > <http://www.google.de/search?q=regen> sind gleiche URLs, da sie sich ja
> > nur durch den Parameter unterscheiden. Das sind unterschiedliche URLs.
Ihnen werden zumindest unterschiedliche SE-Einträge gewidmet.
> Das sind bis auf die Parameter gleiche URLs. Die Parameter zähle ich
> nicht zum URL dazu.
Google, Live.com und jetzt auch Yahoo (ist etwas träge bis zur
Auslieferung seiner Ergebnisse) listen gleiche URLs mit
unterschiedlichen Parametern als unterschiedliche Einträge, BTST.
Fokus ist: Wie gehen SEs damit um.
> Das ist richtig. Aber sie werden ihnen eher folgen als 5.000 *gleichen*
> URLs.
siehe meine Erfahrung in: <news:5esrl4-...@news.wolfgang.ewert.com>
hier im Fred. Yahoo speichert URLs mit Parametern (bis jetzt) nicht
zwischen.
Wolfgang
Gustaf Mossakowski
> Das Schöne an Typo3 ist, dass es so viele Möglichkeiten bietet. Das
> Schreckliche an Typo3 ist, dass es so viele Möglichkeiten bietet.
Eierlegende Wollmilchsau, sozusagen.
> Bei
> Sprachversionen ist es z.B. möglich, alle Dokumente aller Sprachen
> intern (im Backend) innerhalb eines Dokumentenbaumes zu verwalten. Auch
> möglich ist, je Sprache einen eigenen Dokumentenbaum anzulegen. Auch ein
> (für das Frontend simuliertes) Unterverzeichnis /en, /de etc. je Sprache
> ist sicher machbar (mit Typo3 ist alles machbar ...); das braucht die
> entsprechende .htaccess-Regel, weil es in Zusammenarbeit von Server und
> CMS umgesetzt wird.
Typo3 habe ich selber noch nie installiert, da bin ich nur Nutzer und
finde die Vielfalt der Möglichkeiten erdrückend. Sicherlich ist das
alles wegkonfigurierbar, aber der Aufwand dafür ist beträchtlich. Ein
guter Bekannter von mir administriert so eine Website und hat mir
bestätigt, dass die Einarbeitungszeit als Administrator nicht
unerheblich ist. Ein weiterer Nachteil von Typo3 ist der
Ressourcenhunger.
Ich habe bisher neben kompletten Websites häufig auch nur einzelne
Module erstellt, wie z. B. Anmeldeformulare für Veranstaltungen auf
einer Flash-Website, die sich in vorhandene Strukturen integrieren
müssen. Im Laufe der Zeit ist daraus ein modulares, selbst geschriebenes
CMS entstanden, dass ich an meine Bedürfnisse und die der Kunden
wunderbar anpassen kann. Zwangsläufig müssen dabei die URLs sich in
vorhandene Strukturen einpassen, genauso müssen die technischen
Möglichkeiten berücksichtigt werden. Eine Lösung, wie gegenüber Alex
geäußert, statt mod_rewrite URLs über eine Skriptsprache direkt aus dem
Skript zu parsen, mag programmiertechnisch unelegant sein (da ich
mehrere einzelne Skripte brauche, in denen im Prinzip nur andere
eingebunden werden), ist aber manchmal aufgrund der technischen
Gegebenheiten die einzige Lösung. Diese Flexibilität bekomme ich
vielleicht auch mit Typo3, aber da ist die Einarbeitungszeit sicherlich
nicht zu unterschätzen. Meine Zeit für mein CMS sicher auch nicht, das
ist Abwägungssache.
> Es als Option sauber in ein System einzubauen, ist für die Entwickler
> vielleicht nicht mal ein Problem. Aber die Anwender sollen es ja auch
> noch umsetzen können. "Wenn HTML ein Fahrrad ist, dann ist Typo3 ein
> Jumbo Jet", oder so ähnlich sagte mal jemand. Daher auch früher im
> Thread mein Hinweis, dass man sich ein CMS (das gilt wahrscheinlich für
> alle; ich spiele gerade auch mit modX, das mit Einfachheit wirbt) nicht
> ohne Not antun sollte.
Ja, das ist ein Vorteil, wenn man das CMS maßgeschneidert erstellt. Ich
gebe meinen Anwendern die (vorher abgestimmte) URL-Struktur vor, so dass
diese sich kaum bis gar keine Gedanken machen müssen, wie die URLs
später aussehen. Bei Typo3 kann man die URLs für jede Seite einzeln
vergeben, oder?
> Für eine bessere Position sprechender Datei- und evtl. auch
> Verzeichnisnamen in den SERPs spricht aber, dass Übereinstimmungen der
> Abfrage mit dem Ressourcennamen (sogar noch trotz Abweichungen) in den
> Ergebnissen fett formatiert hervorgehoben werden, Bsp. (siehe jeweils
> die grüne Zeile mit dem Ressourcennamen am Ende der Treffer):
> <http://www.google.de/search?q=e-mail+tutorial>
Ah ja, tatsächlich. Ich hatte bisher immer nur gehört, dass es unklar
sei, ob die URL-Bestandteile wirklich für die Suche verwendet werden
oder ausschließlich als Bonus hervorgehoben werden. Aber ich habe mal
gerade getestet, Google findet tatsächlich auch Begriffe, wenn sie nur
in der URL stehen.
<http://www.google.de/search?q=invisible+konzeptrezept> zeigt auf Platz
eins eine Nonsens-Seite, in der das Wort »invisible« nur in der URL
vorkommt, auch nicht in den Linktexten bei den Links zu der Seite.
(Linktext ist immer »Intentionally Blank«).
Das zeigt immerhin, dass die URL einen Einfluß auf die Suchergebnisse
hat, ansonsten ...
> Das ist zwar noch kein Beweis, aber den zu führen wäre, nicht nur wegen
> der 300+ Rankingfaktoren, nicht so einfach: Wenn du eine ansonsten
> identische Ressource auf der gleichen Domain mal mit und mal ohne
> sprechenden Dateinamen anbieten würdest, wäre das schon wieder ein
> Duplicate-Content-Trigger mit Wirkung auf die Aussagekraft des
> Experimentes ...
... gebe ich dir Recht, eine Aussage, wie wichtig die URL z. B. von
Google bewertet wird, ist wohl nur schwierig zu bekommen.
Viele Grüße
Gustaf
Niels Braczek
> Niels Braczek schrieb:
>
>> [Gehören sprechende URLs zum Konzept des WWW oder nicht]
>>> Na, dann sind wir ja zumindest grundsätzlich einer Meinung (sie sind
>>> gut), nur in der Bewertung der Wichtigkeit nicht. Aber da werden wir
>>> sicher auch nicht einer Meinung werden ;-)
>>
>> Das schließe ich nach wie vor nicht aus ;-)
>
> Oh. Na, dann versuche ich es doch nochmal!
;-)
>> Ich stelle hier wirklich nur die Notwendigkeit in Abrede. Für die
>> Akzeptanz bei den Nutzern und den SEs sind sprechende URLs von Vorteil,
>> also sind sie wichtig. Allerdings in Bezug auf den Content nachrangig.
>
> Sicher ist der Inhalt das Wichtigste.
> [...]
> Was ich damit sagen will: sprechende URLs tragen zur Orientierung bei,
> sie können Vertrauen in den Anbieter schaffen und erlauben vielfältige
> Wege durch eine Website. Auf Anbieterseite erlauben sie eine klare
> Strukturierung des Angebots und können auch die Programmierung von
> dynamischen Websites erleichtern. Für mich sind das viele Gründe, die
> für mich verdeutlichen, dass URLs das Grundgerüst einer jeden Website
> zumindest sein sollten, auch wenn das nicht überall so ist. Rein von der
> technischen Seite hast du Recht, technisch notwendig sind die nicht.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Siehst du, schon sind wir uns einig; mir ging es nur um den letzten
Punkt. In Bezug auf die Sinnhaftigkeit und die dringende Empfehlung,
sprechende URLs zu benutzen, gehe ich absolut konform mit dir.
Christoph Schneegans
> Nein, umgekehrt: dass ein URL auf mehrere Ressourcen verweist.
Sag doch gleich, daß du von "Content Negotiation" sprichst.
> Manche Server sind so konfiguriert, dass sie auf einen URL wie
> "example.com/index" mit einer Liste von Dateien antworten, zB.
> "index.html", "index.php", "index.txt".
Das ändert überhaupt nichts; die Ressource ist dann eben nicht "Foo",
sondern bspw. "Die für den anfragenden Benutzeragenten am besten
geeignete Variante von Foo" oder "Eine Auflistung aller Repräsentationen
von Foo".
Eine Ressource kann natürlich mehrere Repräsentationen haben. (Das ist der
Sprachgebrauch von HTTP 1.1; die Apache-Dokumentation spricht auch von
"Varianten".) Aber eine URL verweist immer auf genau eine Ressource.
> Ursprünglich ist der URL daher etwas in der Art von mehrdeutig (genau
> genommen aber doch eindeutig, nämlich falsch; die angeforderte Ressource
> existiert ja nicht).
Natürlich tut sie das. Was zeigt denn der Browser sonst an?
--
<http://schneegans.de/web/xhtml/> · Klare Antworten zu XHTML
Niels Braczek
> Niels Braczek schrieb:
>
>> Nein, umgekehrt: dass ein URL auf mehrere Ressourcen verweist.
>
> Sag doch gleich, daß du von "Content Negotiation" sprichst.
Das Wort fiel mir nicht ein ;-)
>> Ursprünglich ist der URL daher etwas in der Art von mehrdeutig (genau
>> genommen aber doch eindeutig, nämlich falsch; die angeforderte Ressource
>> existiert ja nicht).
>
> Natürlich tut sie das. Was zeigt denn der Browser sonst an?
Das ist wiederum eine Frage der Sichtweise. Wenn eine klare Antwort vom
Server kommt, kann man das als "die angeforderte Ressource" betrachten,
auch wenn es nicht die Ressource ist, die man angefordert hat. Das
brauchen wir aber nicht zu vertiefen, weil das auf sprachliche
Feinheiten hinausläuft, technisch aber alles klar und hinreichend
definiert ist.
Ich wollte mit dem "eindeutig" eigentlich nur klarmachen, dass die
konzeptionellen Voraussetzung überhaupt nichts mit der *Struktur* eines
URLs zu tun haben. Das habe ich offensichtlich nicht deutlich genug
rübergebracht.
Christoph Schneegans
>>> <http://www.w3.org/Provider/Style/URI.html>
>>
>> Ausgerechnet dieser Klassiker propagiert nun aber bedeutungslose URLs und
>> verfolgt damit ein einziges Ziel, nämlich deren Persistenz, und zwar um
>> jeden Preis.
>
> Was gefällt dir nicht? Die Persistenz oder dass das Ziel um jeden Preis
> erreicht werden soll?
Ich halte es für absolut zulässig, einer Ressource eine neue URL zuzuweisen,
wenn die alte URL dabei nicht stirbt, also eine Weiterleitung auf die neue
URL ausführt. Es ist damit auch zulässig, Begriffe in der URL zu verwenden,
die in 200 Jahren vielleicht eine andere Bedeutung haben werden.
Hast du den Text in letzter Zeit eigentlich mal komplett gelesen? _Nur_
das "creation date" soll idealerweise in die URL, denn "putting any
information in the name is asking for trouble". Den Widerspruch, daß man auch
"1998/12/01" in 200 Jahren möglicherweise nicht mehr als den 1. Dezember des
Jahres 1998 nach Christi Geburt interpretiert, löst TBL natürlich auch nicht
auf. Ich würde jedenfalls nicht darauf wetten, daß man in Eurabien in 200
Jahren noch den gregorianischen Kalender verwendet.
Bezeichnenderweise folgt "http://www.w3.org/Provider/Style/URI.html" den
eigenen Empfehlungen nicht.
>> ich würde auch niemals auf die Idee kommen, den "report of the minutes of
>> a meeting of W3C chair people" unter "http://www.w3.org/1998/12/01/chairs"
>> abzulegen.
>
> Naja, Veranstaltungen unter deren Datum abzulegen, ist ja nun kein
> schlechtes Konzept, ganz im Gegenteil, das ist doch sogar ein sehr weit
> verbreitetes Konzept.
Du hast dich hier doch für "sprechende URLs" eingesetzt. Was ist an
"http://www.w3.org/1998/12/01/chairs" sprechend?
"http://www.w3.org/chair/meetings/1998/12/01/" wäre IMO eine sehr gute URL.
Aber das Datum in den Mittelpunkt zu stellen, das halte ich für Unsinn.
Christoph Schneegans
>> Parameter gehören also streng genommen *nicht* zum URL dazu. Ergo sind
>> deine beiden URLs *gleich*.
>
> Eine sehr eigenwillige Definition.
Es gibt aber viele verwirrte Leute von dieser Sorte. Gelegentlich wird auch
behauptet, daß <http://example.org/?foo> und <http://example.org/?bar>
denselben HTTP-Statuscode zurückgeben müßten...
--
<http://schneegans.de/usenet/mid-schreibweisen/> · Postings richtig verlinken
Alexander Schestag
Gustaf Mossakowski wrote:
> Alexander Schestag schrieb:
>> Das sind bis auf die Parameter gleiche URLs. Die Parameter zähle ich
>> nicht zum URL dazu. Das kann man begründen. Zitat Wikipedia aus dem
>> Artikel "URL":
>> "URLs identifizieren eine Ressource über ihren primären
>> Zugriffsmechanismus (häufig oder ftp) und den Ort (engl. location) der
>> Ressource in Computernetzwerken an"
>> Parameter gehören also streng genommen *nicht* zum URL dazu. Ergo sind
>> deine beiden URLs *gleich*.
> Eine sehr eigenwillige Definition. Es gibt auch einen RFC zu URLs,
> <http://www.ietf.org/rfc/rfc1738.txt>, der sagt unter Punkt 3.3:
> | An HTTP URL takes the form:
> | http://<host>:<port>/<path>?<searchpart>
Ok, du hast mich überzeugt. Ich hatte mich von der Tatsache, daß einige
Protokolle Parameter in URLs nicht verarbeiten können, zu der Aussage
hinreißen lassen. Daß der RFC bei der Definition nach Protokollen
unterscheidet, war mir neu. Es gibt aber ein Problem, das in dieselbe
Richtung geht und in der Tat bei dynamisch generierten Seiten, deren URL
sich nur durch Parameter unterscheiden, auftritt: Die *Inhalte* weichen
bei Seiten mit Parametern nicht selten nur ganz wenig voneinander ab.
> Also, ich erkenne in deiner Argumentation immer noch keine Unterstützung
> für deine ursprünglich geäußerte These:
> | Ist aber so. Einer der Gründe ist, daß hinter solchen Seiten mit
> | URL-Parametern oft ein ganzer Rattenschwanz an Seiten steckt und
> | Spider sich totspidern.
>
> Das kann man mit Parametern machen, ohne Parameter,
Mit Paramatern geschieht es aber viel schneller. Bei statischen URLs
kannst du das steuern, bei dynamischen Seiten oft nicht, da oft andere
Einträge in eine Datenbank machenm, die die Parameter der URLs bilden
und somit die Anzahl der möglichen Seiten erhöhen.
> sinnvoll ist beides nicht,
Bei dynamisch generierten Seiten ist es oft nicht zu vermeiden.
> zu Tode suchen wird sich keine Suchmaschine, da solche Seiten
> höchstwahrscheinlich von den Suchmaschinen nicht als wichtig erachtet
> werden (kommt natürlich auf den Inhalt an, es gibt sicher einzelne
> sinnvolle Szenarien, in denen von einer Webseite tausende Links auf
> andere Seiten erfolgen müssen) und daher die Links über einer gewissen
> Zahl nicht mehr verfolgt werden.
Ja, und eben das ist das Problem.
>> Ich auch nicht - nix Wirksames. ;-) Nein, im Ernst, ich versuche, wo
>> immer es geht, URL-Parameter zu vermeiden, schon alleine, weil sie im
>> Zweifelsfalle Sicherheitsprobleme bereiten können. Manchmal geht es aber
>> sinnvollerweise nicht ohne.
> Da helfen wohl nur statische Webseiten. Wenn du die URL irgendwie
> interpretierst, sei es durch ein Skript oder mod_rewrite, hast du, egal
> ob Parameter oder nicht, immer Sicherheitsprobleme.
Parameter bieten aber eine größere Angriffsfläche, weil man aufpassen
muß, daß ein geschützter Bereich z. B. nicht durch eine einfache
Parametermanipulation im URL kompromittiert wird.
Grüße,
Alex
Harald Effenberg
> Niels Braczek <nbra...@freenet.de> wrote:
> > Zu deutsch: "IMO sollte man sich das Geld Backlinks kaufen."
> ^
> ... für ...
Und man sollte in seinem Newsreader eine Festbreitenschrift für
die Darstellung wählen. ;-)
Viele Grüße
Harald
--
Wenn es sonst keine Themen gibt kann man das Usenet ja zumachen.
(Utz Pflock in dan-an)
Gustaf Mossakowski
> Es gibt aber ein Problem, das in dieselbe
> Richtung geht und in der Tat bei dynamisch generierten Seiten, deren URL
> sich nur durch Parameter unterscheiden, auftritt: Die *Inhalte* weichen
> bei Seiten mit Parametern nicht selten nur ganz wenig voneinander ab.
Das kommt darauf an. Ein Test bei einer der von mir am häufigsten
aufgerufenen Seiten konnte ich das nicht feststellen:
<http://www.google.de/search?q=wetter> unterscheidet sich doch deutlich
von <http://www.google.de/search?q=kettcar>, obwohl ich nur zwei
Buchstaben in den Parametern ausgetauscht habe.
Wenn du Seiten mit Session-IDs meinst: z. B. die Suche nach der
PHP-Session-ID <http://www.google.de/search?q=inurl%3APHPSESSID> zeigt
tatsächlich ca. 31 Mio. Treffer, aber z. B. die Suche nach
<http://www.google.de/search?q=inurl%3APHPSESSID+site%3Afplusd.org>
zeigt, dass die einzelnen Seiten (zumindest auf den ersten Blick) nicht
vielfach unter mehreren Session-IDs im Index auftauchen.
>> | Ist aber so. Einer der Gründe ist, daß hinter solchen Seiten mit
>> | URL-Parametern oft ein ganzer Rattenschwanz an Seiten steckt und
>> | Spider sich totspidern.
>>
>> Das kann man mit Parametern machen, ohne Parameter,
>
> Mit Paramatern geschieht es aber viel schneller. Bei statischen URLs
> kannst du das steuern, bei dynamischen Seiten oft nicht, da oft andere
> Einträge in eine Datenbank machenm, die die Parameter der URLs bilden
> und somit die Anzahl der möglichen Seiten erhöhen.
Also, das klingt nun eher nach einer kaputten Programmierung der
zugrundeliegenden Skripte oder des CMS. Wenn ich ein Wordpress-Blog
betriebe, und jemand anders erlaubte, einen Beitrag zu schreiben,
entstehen dadurch doch nicht ungewollt plötzlich zig neue URLs.
>> sinnvoll ist beides nicht,
>
> Bei dynamisch generierten Seiten ist es oft nicht zu vermeiden.
Ich verstehe es glaube ich immer noch nicht, so langsam bekomme ich aber
das Gefühl, dass wir aneinander vorbeireden. Vielleicht hast du ein
Beispiel für so eine Website?
>> zu Tode suchen wird sich keine Suchmaschine, [...]
>
> Ja, und eben das ist das Problem.
Aber doch nur, wenn ich tausende Seiten wirklich indizieren lassen will,
nicht wenn das »aus Versehen« geschieht. Und wenn ich wirklich 1.000
Seiten aufnehmen lassen will, die inhaltlich interessant sind, klappt
das schon.
> Parameter bieten aber eine größere Angriffsfläche, weil man aufpassen
> muß, daß ein geschützter Bereich z. B. nicht durch eine einfache
> Parametermanipulation im URL kompromittiert wird.
Das hat aber auch nichts primär mit Parametern zu tun, sondern mit dem
Sicherheitskonzept und ggf. auch mit dem URL-Konzept. Wenn ich unter
example.org/content.html den Inhalt und unter
example.org/content.html?mode=admin die Administration des Inhalts
erreiche, ohne Paßwortschutz, ist das grob fahrlässig und keine Gefahr,
die durch den Gebrauch von Parametern in der URL entsteht. Den gleichen
Müll könnte ich auch über example.org/content.html und
example.org/admin/edit/content.html oder so erreichen.
Letzteres hatte ich mal bei einer übernommenen Website, gottseidank mit
Framesets, so dass man nicht sah, dass alle Inhalte im Ordner /admin/
lagen. Unter /admin/ erreichte man eine Paßwortabfrage, die auf
/admin/index2.php weiterleitete. Die Inhalte darunter waren völlig
ungeschützt, unter /admin/kategorie/ erreichte man die Administration,
unter /admin/kategorie/seite1.html den Seiteninhalt, der auch direkt so
verlinkt wurde. Ein Wunder, dass nie jemand sich an der Admin-Oberfläche
zu schaffen gemacht hat.
Viele Grüße
Gustaf
Alexander Schestag
> Alexander Schestag schrieb:
>
>> Es gibt aber ein Problem, das in dieselbe
>> Richtung geht und in der Tat bei dynamisch generierten Seiten, deren URL
>> sich nur durch Parameter unterscheiden, auftritt: Die *Inhalte* weichen
>> bei Seiten mit Parametern nicht selten nur ganz wenig voneinander ab.
> Das kommt darauf an. Ein Test bei einer der von mir am häufigsten
> aufgerufenen Seiten konnte ich das nicht feststellen:
> <http://www.google.de/search?q=wetter> unterscheidet sich doch deutlich
> von <http://www.google.de/search?q=kettcar>, obwohl ich nur zwei
> Buchstaben in den Parametern ausgetauscht habe.
Es kommt natürlich darauf an, wie der Content aufgebaut ist. Bei Google
oder einer anderen Suchmaschine ist es völlig klar, daß der Content
stark variiert. Nimm aber z. B. eine Produktsuchseite für ein eng
umfaßtes Produktangebot, z. B. Autos. nehmen wir an, ein URL-Parameter m
definiert die Marke. Die Datenbank kennt 1000 Marken. Also können durch
eine Suche bis zu 1000 Einzelseiten durch die Änderung nur eines
einzelnen Parameters m dynamisch generiert werden. Es kann nun sein, daß
sich diese 1000 Einzelseiten nur durch die Angabe des Markennamens, des
Preises und eines Bildes unterscheiden und der restliche Content gleich
bleibt.
>> Mit Paramatern geschieht es aber viel schneller. Bei statischen URLs
>> kannst du das steuern, bei dynamischen Seiten oft nicht, da oft andere
>> Einträge in eine Datenbank machenm, die die Parameter der URLs bilden
>> und somit die Anzahl der möglichen Seiten erhöhen.
> Also, das klingt nun eher nach einer kaputten Programmierung der
> zugrundeliegenden Skripte oder des CMS. Wenn ich ein Wordpress-Blog
> betriebe, und jemand anders erlaubte, einen Beitrag zu schreiben,
> entstehen dadurch doch nicht ungewollt plötzlich zig neue URLs.
Natürlich nicht, wenn du nur einer Person das erlaubst. Aber wenn du das
10.000 Leuten erlaubst, sieht es evtl. anders aus. Suchmaschinen machen
es genauso. Jede Änderung des q-Parameters für den Suchbegriff bei
Google bewirkt die dynamische Generierung einer neuen Suchergebnis-Seite
aus einer Datenbank. So können bei diesem Extrembeispiel unter
http://www.google.de durch Änderung nur eines einzigen Parameters
Millionen unterschiedliche Einzelseiten entstehen. Nun nimm eine
Produktsuchseite, die von der URL-Konstruktion her genauso aufgebaut ist.
>>> sinnvoll ist beides nicht,
>> Bei dynamisch generierten Seiten ist es oft nicht zu vermeiden.
> Ich verstehe es glaube ich immer noch nicht, so langsam bekomme ich aber
> das Gefühl, dass wir aneinander vorbeireden. Vielleicht hast du ein
> Beispiel für so eine Website?
Du hast das beste Beispiel oben genannt, Google. Jede Veränderung eines
einzelnen Parameters erzeugt eine neue, dynamisch generierte Einzelseite.
>> Parameter bieten aber eine größere Angriffsfläche, weil man aufpassen
>> muß, daß ein geschützter Bereich z. B. nicht durch eine einfache
>> Parametermanipulation im URL kompromittiert wird.
> Das hat aber auch nichts primär mit Parametern zu tun, sondern mit dem
> Sicherheitskonzept und ggf. auch mit dem URL-Konzept.
Die Parameter würde ich da dazuzählen.
> Wenn ich unter example.org/content.html den Inhalt und unter
> example.org/content.html?mode=admin die Administration des Inhalts
> erreiche, ohne Paßwortschutz, ist das grob fahrlässig und keine Gefahr,
> die durch den Gebrauch von Parametern in der URL entsteht.
Es kommt drauf an.
> Den gleichen Müll könnte ich auch über example.org/content.html und
> example.org/admin/edit/content.html oder so erreichen.
Wenn das so organisiert ist, daß durch Wechseln des Parameters einfach
das Verzeichnis gewechselt wird, hast du Recht. Es gibt aber m. E.
deutlich mehr Fälle, in denen mit Parametern Daten aus Datenbanken
ausgelesen werden, mit deren Hilfe dann Seiten dynamisch
zusammengebastelt werden. Hier bringt dich dein alternatives Vorgehen
nicht weiter, weil eben kein Unterverzeichnis existiert. Da kommt man
dann nur mit Parametermanipulation weiter. Natürlich sind auch da die
Parameter nicht direkt das Problem, aber sie sprechen den Spieltrieb an. ;-)
Grüße,
Alex
Gustaf Mossakowski
> Gustaf Mossakowski wrote:
>> Alexander Schestag schrieb:
>>
>>> Es gibt aber ein Problem, das in dieselbe Richtung geht und in der
>>> Tat bei dynamisch generierten Seiten, deren URL sich nur durch
>>> Parameter unterscheiden, auftritt: Die *Inhalte* weichen bei Seiten
>>> mit Parametern nicht selten nur ganz wenig voneinander ab.
>
>> <http://www.google.de/search?q=wetter> unterscheidet sich doch
>> deutlich von <http://www.google.de/search?q=kettcar>, obwohl ich nur
>> zwei Buchstaben in den Parametern ausgetauscht habe.
>
> Es kommt natürlich darauf an, wie der Content aufgebaut ist. Bei Google
> oder einer anderen Suchmaschine ist es völlig klar, daß der Content
> stark variiert.
OK.
> Nimm aber z. B. eine Produktsuchseite für ein eng
> umfaßtes Produktangebot, z. B. Autos. nehmen wir an, ein URL-Parameter m
> definiert die Marke. Die Datenbank kennt 1000 Marken. Also können durch
> eine Suche bis zu 1000 Einzelseiten durch die Änderung nur eines
> einzelnen Parameters m dynamisch generiert werden. Es kann nun sein, daß
> sich diese 1000 Einzelseiten nur durch die Angabe des Markennamens, des
> Preises und eines Bildes unterscheiden und der restliche Content gleich
> bleibt.
1. Wir reden jetzt über Suchergebnisse, da gibt es natürlich viele URLs.
Konsequent wäre es von einer Suchmaschine, wenn sie keine Treffer
findet, einen 404-Fehlercode zurückzugeben.
<http://www.google.de/search?q=fgjntnhortnhtrh> macht das nicht.
Suchergebnisse werden aber auch normalerweise nicht von der Startseite
direkt verlinkt.
2. Wenn auf jeder der 1.000 Einzelseiten ein anderes Auto beschrieben
wird (was ich wegen der Änderung des Marken- oder Produktnamens
annehme), dann ist das doch okay und es sind wirklich 1.000 verschiedene
Autos, die dargestellt werden. Das ist so wie bei ebay, da sind die
Inhalte auch ähnlich. Panini-Fußballbilder, da gibt's momentan 24
Angebote, die sind sehr ähnlich, aber doch jedes individuell. Ich sehe
da nicht direkt das Problem. Abgesehen von ebays grausigen URLs, die
allerdings ohne Parameter auskommen.
<http://search.ebay.de/panini-fussballbilder_W0QQ_trksidZm37QQfromZR40QQs
atitleZpaniniQ2dfuQdfballbilder>. Viele andere Seiten funktionieren auch
so. YouTube, Flickr, del.icio.us, alle tauschen nur wenige Parameter
oder andere Bestandteile der URL aus, und schon kommt in einer
vertrauten Struktur ein anderer Inhalt.
>>> Mit Paramatern geschieht es aber viel schneller. Bei statischen
>>> URLs kannst du das steuern, bei dynamischen Seiten oft nicht, da
>>> oft andere Einträge in eine Datenbank machenm, die die Parameter
>>> der URLs bilden und somit die Anzahl der möglichen Seiten erhöhen.
>
>> Also, das klingt nun eher nach einer kaputten Programmierung der
>> zugrundeliegenden Skripte oder des CMS. Wenn ich ein Wordpress-Blog
>> betriebe, und jemand anders erlaubte, einen Beitrag zu schreiben,
>> entstehen dadurch doch nicht ungewollt plötzlich zig neue URLs.
>
> Natürlich nicht, wenn du nur einer Person das erlaubst. Aber wenn du das
> 10.000 Leuten erlaubst, sieht es evtl. anders aus.
Nein, wenn ich 10.000 Leute auffordere und erlaube, einen Beitrag zu
schreiben, gibt es 10.000 Beiträge, vermutlich eher weniger, keinesfalls
mehr. Das ist dann eine große Summe, ja, aber auch hier gibt es keinen
Unterschied zwischen statischen und dynamischen Seiten, Parametern und
parameterlosen URLs.
> Suchmaschinen machen
> es genauso. Jede Änderung des q-Parameters für den Suchbegriff bei
> Google bewirkt die dynamische Generierung einer neuen Suchergebnis-Seite
> aus einer Datenbank. So können bei diesem Extrembeispiel unter
> http://www.google.de durch Änderung nur eines einzigen Parameters
> Millionen unterschiedliche Einzelseiten entstehen. Nun nimm eine
> Produktsuchseite, die von der URL-Konstruktion her genauso aufgebaut ist.
Deine Aussage war ja:
| Ist aber so. Einer der Gründe ist, daß hinter solchen Seiten mit
| URL-Parametern oft ein ganzer Rattenschwanz an Seiten steckt und
| Spider sich totspidern.
Ich denke nicht, dass es für eine Suchmaschine empfehlenswert ist,
Suchergebnis-Listen zu indizieren. Macht auch kaum eine.
>>> Parameter bieten aber eine größere Angriffsfläche, weil man
>>> aufpassen muß, daß ein geschützter Bereich z. B. nicht durch eine
>>> einfache Parametermanipulation im URL kompromittiert wird.
>
>> Das hat aber auch nichts primär mit Parametern zu tun, sondern mit
>> dem Sicherheitskonzept und ggf. auch mit dem URL-Konzept.
>
> Die Parameter würde ich da dazuzählen.
Ja, ich auch. Du schriebst aber, dass Parameter in URLs eine _größere_
Angriffsfläche für geschützte Bereiche bieten als andere Bestandteile
der URL. Das mag zutreffen, wenn man normalerweise nur statische
Webseiten hat und seinen geschützten Bereich z. B. mit mod_auth von
Apache sichert und nun das erste Mal mit einer Skriptsprache und
Parametern hantiert und versucht, alle Logik in ein Skript zu packen,
dass mit verschiedenen Parametern angesteuert wird. Dann ist natürlich
die alte Variante, statische Webseiten auszuliefern, sicherer. Da kann
kaum was passieren. Bei einer dynamischen Website, unabhängig vom
URL-Design muß ich mir natürlich deutlich mehr Gedanken um die
Sicherheit machen. Das liegt aber in der Natur der Dynamik, nicht an den
Parametern.
>> Wenn ich unter example.org/content.html den Inhalt und unter
>> example.org/content.html?mode=admin die Administration des Inhalts
>> erreiche, ohne Paßwortschutz, ist das grob fahrlässig und keine
>> Gefahr, die durch den Gebrauch von Parametern in der URL entsteht.
>
> Es kommt drauf an.
Nein, in diesem Fall ist das grob fahrlässig und wenn Schäden entstehen
und du für dieses Konstrukt verantwortlich bist, müsstest du also
haften.
>> Den gleichen Müll könnte ich auch über example.org/content.html und
>> example.org/admin/edit/content.html oder so erreichen.
>
> Wenn das so organisiert ist, daß durch Wechseln des Parameters einfach
> das Verzeichnis gewechselt wird, hast du Recht.
Das verstehe ich nicht.
> Es gibt aber m. E.
> deutlich mehr Fälle, in denen mit Parametern Daten aus Datenbanken
> ausgelesen werden, mit deren Hilfe dann Seiten dynamisch
> zusammengebastelt werden. Hier bringt dich dein alternatives Vorgehen
> nicht weiter, weil eben kein Unterverzeichnis existiert. Da kommt man
> dann nur mit Parametermanipulation weiter. Natürlich sind auch da die
> Parameter nicht direkt das Problem, aber sie sprechen den Spieltrieb an. ;-)
Wunderbar. Das ist doch meine Aussage. Parameter sind nicht direkt das
Problem.
Es ist übrigens auch eine Aufgabe des URL-Designs, ob mit Query Strings
oder ohne, die Komplexität gering zu halten. Das wäre eine Kritik an
Joomla 1.0.x, das hier z. B. URLs wie
example.com/index.php?option=com_content&task=section&id=12&Itemid=31
erstellt, und bei Änderung der Itemid denselben Inhalt, aber
unterschiedlich angewählte Menüs ausgibt. Und alle mit Statuscode 200.
In meinen Augen ergibt das keinen Sinn. Da hat sich dann wohl niemand
Gedanken gemacht.
Viele Grüße
Gustaf
Alexander Schestag
ich kürze mal massiv, weil mittlerweile überwiegend Konsens besteht.
Gustaf Mossakowski wrote:
> Alexander Schestag schrieb:
>> Nimm aber z. B. eine Produktsuchseite für ein eng
>> umfaßtes Produktangebot, z. B. Autos. nehmen wir an, ein URL-Parameter m
>> definiert die Marke. Die Datenbank kennt 1000 Marken. Also können durch
>> eine Suche bis zu 1000 Einzelseiten durch die Änderung nur eines
>> einzelnen Parameters m dynamisch generiert werden. Es kann nun sein, daß
>> sich diese 1000 Einzelseiten nur durch die Angabe des Markennamens, des
>> Preises und eines Bildes unterscheiden und der restliche Content gleich
>> bleibt.
> 1. Wir reden jetzt über Suchergebnisse, da gibt es natürlich viele URLs.
Richtig. Und solche URLs werden teilweise auch von Suchmaschinen indiziert.
> Konsequent wäre es von einer Suchmaschine, wenn sie keine Treffer
> findet, einen 404-Fehlercode zurückzugeben.
Wieso? 404 heißt "Seite nicht gefunden", nicht "Suchwort nicht gefunden".
> <http://www.google.de/search?q=fgjntnhortnhtrh> macht das nicht.
Wäre auch falsch bzw. mißbräuchliche Verwendung eines 404er.
> 2. Wenn auf jeder der 1.000 Einzelseiten ein anderes Auto beschrieben
> wird (was ich wegen der Änderung des Marken- oder Produktnamens
> annehme), dann ist das doch okay und es sind wirklich 1.000 verschiedene
> Autos, die dargestellt werden. Das ist so wie bei ebay, da sind die
> Inhalte auch ähnlich. Panini-Fußballbilder, da gibt's momentan 24
> Angebote, die sind sehr ähnlich, aber doch jedes individuell. Ich sehe
> da nicht direkt das Problem.
Zu wenig unterschiedlicher Content.
> Deine Aussage war ja:
>
> | Ist aber so. Einer der Gründe ist, daß hinter solchen Seiten mit
> | URL-Parametern oft ein ganzer Rattenschwanz an Seiten steckt und
> | Spider sich totspidern.
> Ich denke nicht, dass es für eine Suchmaschine empfehlenswert ist,
> Suchergebnis-Listen zu indizieren. Macht auch kaum eine.
Das geht auch nicht, denn dann müßte die Suchmaschine ja einen
Suchbegriff eingeben. ;-)
>>>> Parameter bieten aber eine größere Angriffsfläche, weil man
>>>> aufpassen muß, daß ein geschützter Bereich z. B. nicht durch eine
>>>> einfache Parametermanipulation im URL kompromittiert wird.
>>> Das hat aber auch nichts primär mit Parametern zu tun, sondern mit
>>> dem Sicherheitskonzept und ggf. auch mit dem URL-Konzept.
>> Die Parameter würde ich da dazuzählen.
> Ja, ich auch. Du schriebst aber, dass Parameter in URLs eine _größere_
> Angriffsfläche für geschützte Bereiche bieten als andere Bestandteile
> der URL. Das mag zutreffen, wenn man normalerweise nur statische
> Webseiten hat und seinen geschützten Bereich z. B. mit mod_auth von
> Apache sichert und nun das erste Mal mit einer Skriptsprache und
> Parametern hantiert und versucht, alle Logik in ein Skript zu packen,
> dass mit verschiedenen Parametern angesteuert wird. Dann ist natürlich
> die alte Variante, statische Webseiten auszuliefern, sicherer. Da kann
> kaum was passieren. Bei einer dynamischen Website, unabhängig vom
> URL-Design muß ich mir natürlich deutlich mehr Gedanken um die
> Sicherheit machen. Das liegt aber in der Natur der Dynamik, nicht an den
> Parametern.
Doch, das liegt *auch* an den Parametern bzw. deren bloßer Existenz.
Nimm als Beispiel
a.) http://www.irgendeinshop.de/custom.php?kundenid=1
und
b.) http://www.irgendeinshop.de/custom.php
mit dem gleichen dynamisch generierten Content, nämlich eine
personalisierte Kundenseite. in Beispiel a.) ist es durch einfache
Parametermanipulation deutlich einfacher, eine Lücke auszunützen, die
darin besteht, daß durch Einsetzen einer anderen Zahl in der Variable
kundenid ein unautorisierter Zugriff auf fremde Kundendaten möglich ist,
weil diese nicht ausreichend geschützt wurden. In Beispiel b.) muß ich
mich mehr anstrengen, um die gleiche Lücke auszunutzen. Nein, ich will
damit nicht sagen, daß b.) sicherer ist. Aber a.) macht es einem
Angreifer *noch* leichter, weil ihm die entscheidenden Variablen in den
URL-Parametern gleich mitgeliefert werden.
>>> Wenn ich unter example.org/content.html den Inhalt und unter
>>> example.org/content.html?mode=admin die Administration des Inhalts
>>> erreiche, ohne Paßwortschutz, ist das grob fahrlässig und keine
>>> Gefahr, die durch den Gebrauch von Parametern in der URL entsteht.
>> Es kommt drauf an.
> Nein, in diesem Fall ist das grob fahrlässig und wenn Schäden entstehen
> und du für dieses Konstrukt verantwortlich bist, müsstest du also
> haften.
Das meinte ich nicht mit "Es kommt drauf an", sondern daß es von
verschiedenen Bedingungen abhängt, ob der Gebrauch von Parametern im URL
hier entscheidend zu der Lücke beiträgt oder nicht.
Ob man für dieses Konstrukt haftbar zu machen ist, ist noch eine andere
Frage.
>>> Den gleichen Müll könnte ich auch über example.org/content.html und
>>> example.org/admin/edit/content.html oder so erreichen.
>> Wenn das so organisiert ist, daß durch Wechseln des Parameters einfach
>> das Verzeichnis gewechselt wird, hast du Recht.
> Das verstehe ich nicht.
example.org/admin/edit/content.html ist bei dir identisch mit
example.org/content.html?mode=admin. Ich hatte dich so verstanden, daß
der Parameter in dem Fall dafür sorgt, daß Daten für die Seite aus dem
Verzeichnis /admin geholt werden.
>> Es gibt aber m. E.
>> deutlich mehr Fälle, in denen mit Parametern Daten aus Datenbanken
>> ausgelesen werden, mit deren Hilfe dann Seiten dynamisch
>> zusammengebastelt werden. Hier bringt dich dein alternatives Vorgehen
>> nicht weiter, weil eben kein Unterverzeichnis existiert. Da kommt man
>> dann nur mit Parametermanipulation weiter. Natürlich sind auch da die
>> Parameter nicht direkt das Problem, aber sie sprechen den Spieltrieb an. ;-)
> Wunderbar. Das ist doch meine Aussage. Parameter sind nicht direkt das
> Problem.
Aber sie machen ein Eindringen noch deutlich leichter, weil du einem
Einbrecher das Brecheisen direkt vor die Nase hältst. Bekannte
URL-Parameter zu manipulieren ist nun mal deutlich einfacher, als
unbekannte Verzeichnisse zu erraten wie in deinem Beispiel.
> Es ist übrigens auch eine Aufgabe des URL-Designs, ob mit Query Strings
> oder ohne, die Komplexität gering zu halten.
Da gebe ich dir recht.
Grüße,
Alex
Frank Müller
>> 2. Wenn auf jeder der 1.000 Einzelseiten ein anderes Auto beschrieben
>> wird (was ich wegen der Änderung des Marken- oder Produktnamens
>> annehme), dann ist das doch okay und es sind wirklich 1.000
>> verschiedene Autos, die dargestellt werden. Das ist so wie bei ebay,
>> da sind die Inhalte auch ähnlich. Panini-Fußballbilder, da gibt's
>> momentan 24 Angebote, die sind sehr ähnlich, aber doch jedes
>> individuell. Ich sehe da nicht direkt das Problem.
> Zu wenig unterschiedlicher Content.
Wie meinst du das jetzt?
Auf einer Site (Autohaus) x Fahrzeuge die unterschiedlich sind
oder auf einer Site (Ebay) x Angebote die relativ gleich sind?
Oder aber Produkt A eines Herstellers wird in x
Onlineshops vertrieben (unterschiedliche Sites), aber
die Beschreibung ist in allen Shops nahezu identisch.
>> Deine Aussage war ja:
>>> Ist aber so. Einer der Gründe ist, daß hinter solchen Seiten mit
>>> URL-Parametern oft ein ganzer Rattenschwanz an Seiten steckt und
>>> Spider sich totspidern.
>
>> Ich denke nicht, dass es für eine Suchmaschine empfehlenswert ist,
>> Suchergebnis-Listen zu indizieren. Macht auch kaum eine.
>
> Das geht auch nicht, denn dann müßte die Suchmaschine ja einen
> Suchbegriff eingeben. ;-)
Das geht schon. Denn oft ist es ja so, dass die
Suchseite z.B. Artikelsuche.php indiziert wird.
Und wenn der User nichts eingibt an Suchbegriff
wird nur per clientseitigem Begriff die Meldung ausgegeben,
dass man einen Suchbegriff eingeben soll. Serverseitig wird
nicht geprüft und schwupps erhält die Suchmaschine ALLE
Artikel weil sie JavaScript nicht interpretiert. Und schon sind
die Seiten erfasst.
> Doch, das liegt *auch* an den Parametern bzw. deren bloßer Existenz.
> Nimm als Beispiel
>
> a.) http://www.irgendeinshop.de/custom.php?kundenid=1
>
> und
>
> b.) http://www.irgendeinshop.de/custom.php
>
> mit dem gleichen dynamisch generierten Content, nämlich eine
> personalisierte Kundenseite. in Beispiel a.) ist es durch einfache
> Parametermanipulation deutlich einfacher, eine Lücke auszunützen, die
> darin besteht, daß durch Einsetzen einer anderen Zahl in der Variable
> kundenid ein unautorisierter Zugriff auf fremde Kundendaten möglich
> ist, weil diese nicht ausreichend geschützt wurden.
Wer macht den so was heutzutage noch? Wenn ich durch
Austausch von meiner ...kundenid=1 zu kundenid=2
fremde Kundendaten bearbeiten könnte, würde ich sofort
den Provider wechseln. Da muß zwingend eine Anmeldung
kommen mit der ich mich über Username / Passwort / Kundennummer
oder was auch immer identifizieren muss, damit ich die Daten
bearbeiten kann. Ich glaube da lebst du in der Steinzeit,
dass so etwas noch möglich ist.
> In Beispiel b.)
> muß ich mich mehr anstrengen, um die gleiche Lücke auszunutzen. Nein,
> ich will damit nicht sagen, daß b.) sicherer ist. Aber a.) macht es
> einem
> Angreifer *noch* leichter, weil ihm die entscheidenden Variablen in
> den URL-Parametern gleich mitgeliefert werden.
Sehe ich nicht so, denn beide Varianten können gleich sicher
umgesetzt werden. Wenn sie falsch umgesetzt werden, dann
sind ich auch gleich unsicher. So etwas regelt man
vernünftigerweise über die Zugriffsrechte auf die Seiten
unabhängig davon wie sie aufgerufen werden / werden können.
>> Wunderbar. Das ist doch meine Aussage. Parameter sind nicht direkt
>> das Problem.
> Aber sie machen ein Eindringen noch deutlich leichter, weil du einem
> Einbrecher das Brecheisen direkt vor die Nase hältst. Bekannte
> URL-Parameter zu manipulieren ist nun mal deutlich einfacher, als
> unbekannte Verzeichnisse zu erraten wie in deinem Beispiel.
Nein nicht wirklich, denn sehen wir es mal so:
Eine Haustür ist nicht mehr oder weniger unsicher ob
das Brecheisen vor der Tür liegt oder ob es der Einbrecher
selbst mitbringt. Und der Haustür ist es auch völlig egal
woher das Brecheisen kommt, entweder sie hält stand oder
auch nicht. Also sollte man seine Haustür sicher machen,
nicht mehr und nicht weniger.
Das Sprichwort: "Gelegenheit macht Diebe" ist zwar allgemein
bekannt und auch richtig, aber wenn wir hier davon reden,
dann wäre das ungefähr so als wenn die Hausbesitzer
mal eben in Urlaub fahren und ihre Haustür offen lassen.
(Braucht dann nicht mal ein Brecheisen mitgebracht zu werden)
Also das jetzt an Parametern in der URL festzumachen ist
meiner persönlichen Meinung nach absoluter Quatsch, da
müssen andere Sicherheitsmechanismen greifen.
Gruß,
Frank
Niels Braczek
> Es ist übrigens auch eine Aufgabe des URL-Designs, ob mit Query Strings
> oder ohne, die Komplexität gering zu halten. Das wäre eine Kritik an
> Joomla 1.0.x, das hier z. B. URLs wie
> example.com/index.php?option=com_content&task=section&id=12&Itemid=31
> erstellt, und bei Änderung der Itemid denselben Inhalt, aber
> unterschiedlich angewählte Menüs ausgibt. Und alle mit Statuscode 200.
> In meinen Augen ergibt das keinen Sinn. Da hat sich dann wohl niemand
> Gedanken gemacht.
Das kannst du so nicht sagen. Wenndas für dich keinen Sinn macht, zeigt
das nur, dass du Joomla! nicht sehr gut kennst.
Die Itemid zur Menü-Selektion ist historisch gewachsen (Mambo-Erbe).
Niemand ist wirklich glücklich damit, aber man wird sie leider nicht so
ohne Weiteres wieder los. Hinter dem durch die Itemid spezifizierten
Menüeintrag steckt nämlich eine sehr weit reichende
Konfigurationsmöglichkeit, die sehr unterschiedliche Darstellungen des
eigentlichen Inhalts ermöglicht. Der von dir genannte URL lässt einen
ganzen Bereich (Section) mit der ID 12 anzeigen. Das kann in Blog-Form,
als Link-Liste der enthaltenen Artikel oder auch nur der Kategorien oder
in noch anderen Formen geschehen, je nachdem, was unter der Itemid
konfiguriert wurde. Es hat sich da also sehr wohl jemand Gedanken
gemacht - auch wenn sich das Ergebnis als nicht ganz so glücklich
erwiesen hat.
Gustaf Mossakowski
>> [Joomla 1.0.x:
>> example.com/index.php?option=com_content&task=section&id=12&Itemid=31]
>
> Das kannst du so nicht sagen. Wenndas für dich keinen Sinn macht, zeigt
> das nur, dass du Joomla! nicht sehr gut kennst.
Allerdings.
> Die Itemid zur Menü-Selektion ist historisch gewachsen (Mambo-Erbe).
> Niemand ist wirklich glücklich damit, aber man wird sie leider nicht so
> ohne Weiteres wieder los. Hinter dem durch die Itemid spezifizierten
> Menüeintrag steckt nämlich eine sehr weit reichende
> Konfigurationsmöglichkeit, die sehr unterschiedliche Darstellungen des
> eigentlichen Inhalts ermöglicht. Der von dir genannte URL lässt einen
> ganzen Bereich (Section) mit der ID 12 anzeigen. Das kann in Blog-Form,
> als Link-Liste der enthaltenen Artikel oder auch nur der Kategorien oder
> in noch anderen Formen geschehen, je nachdem, was unter der Itemid
> konfiguriert wurde. Es hat sich da also sehr wohl jemand Gedanken
> gemacht - auch wenn sich das Ergebnis als nicht ganz so glücklich
> erwiesen hat.
Ja, das Problem ist da doch, dass ich die Konfiguration auf CMS-Seite
einstellen und nicht alle Möglichkeiten veröffentlichen will (auch wenn
sie nicht verlinkt sind). Das zeigt für mich ganz deutlich, dass da
jemand URLs nicht verstanden hat. Und es bestätigt meine Aussage, dass
man sich um das URL-Design zuerst Gedanken machen muß und dass es keine
zusätzliche, nachher überstülpbare Sache ist, sondern halt Teil des
Grundgerüsts. Joomla 1.0.x hat noch weitere derartige unerfreuliche
Dinge, dass es denselben Inhalt unter verschiedenen URLs veröffentlicht,
wenn man nicht genau aufpasst.
Viele Grüße
Gustaf
Gustaf Mossakowski
>>>> <http://www.w3.org/Provider/Style/URI.html>
>
> Ich halte es für absolut zulässig, einer Ressource eine neue URL zuzuweisen,
> wenn die alte URL dabei nicht stirbt, also eine Weiterleitung auf die neue
> URL ausführt. Es ist damit auch zulässig, Begriffe in der URL zu verwenden,
> die in 200 Jahren vielleicht eine andere Bedeutung haben werden.
Darauf geht der Text nicht direkt ein. Aber am Anfang schreibt
Berners-Lee, dass man nicht-optimale Strukturen neu planen darf und auch
sollte.
> Hast du den Text in letzter Zeit eigentlich mal komplett gelesen? _Nur_
> das "creation date" soll idealerweise in die URL, denn "putting any
> information in the name is asking for trouble". Den Widerspruch, daß man auch
> "1998/12/01" in 200 Jahren möglicherweise nicht mehr als den 1. Dezember des
> Jahres 1998 nach Christi Geburt interpretiert, löst TBL natürlich auch nicht
> auf. Ich würde jedenfalls nicht darauf wetten, daß man in Eurabien in 200
> Jahren noch den gregorianischen Kalender verwendet.
Wenn in 200 Jahren URLs überhaupt noch eine Rolle spielen ... Dass man
das nicht so strikt sehen sollte, erschließt sich meines Erachtens
direkt aus der URL des Textes selber - da ist überhaupt kein Verweis auf
ein Datum drin. Aber ich bin bei vielen Projekten darauf gestoßen, dass
das Ordnungsprinzip »Datum« nicht das schlechteste ist.
> Bezeichnenderweise folgt "http://www.w3.org/Provider/Style/URI.html" den
> eigenen Empfehlungen nicht.
Es ist ja noch nichtmal ausschließlich unter einer URL zu erreichen.
Ohne .html funktioniert es auch.
> Du hast dich hier doch für "sprechende URLs" eingesetzt. Was ist an
> "http://www.w3.org/1998/12/01/chairs" sprechend?
Daran kann ich erkennen, dass es sich um einen Termin am 1.12.1998
handelt, »chairs« kann ich nicht auf anhieb entschlüsseln,
möglicherweise komme ich auf »W3C Chair«. Soo schlecht ist die URL
nicht, auch wenn ich den letzten Teil »chairs« etwas ausführlicher
beschreiben würde.
> "http://www.w3.org/chair/meetings/1998/12/01/" wäre IMO eine sehr gute URL.
> Aber das Datum in den Mittelpunkt zu stellen, das halte ich für Unsinn.
Die ist auch gut. Aber wonach man ordnet, ist letztlich auch dem eigenen
Ordnungsempfinden überlassen. Daher ist das Datum eine gute
Ordnungsstruktur, da die fast jeder versteht. Ich würde auf jeden Fall
eine URL /chair/meetings/ erstellen, die dann ggf. auf
/chair/meetings/1998/12/01/ oder halt auf /1998/12/01/chair-meeting
verlinkt. Die URL-Struktur muß ja nicht die Haupthierarchie der Website
abbilden.
Viele Grüße
Gustaf
Gustaf Mossakowski
>> Konsequent wäre es von einer Suchmaschine, wenn sie keine Treffer
>> findet, einen 404-Fehlercode zurückzugeben.
>
> Wieso? 404 heißt "Seite nicht gefunden", nicht "Suchwort nicht gefunden".
| The server has not found anything matching the Request-URI
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html>
Könnte man so interpretieren. Kann man auch anders.
>> 2. Wenn auf jeder der 1.000 Einzelseiten ein anderes Auto
>> beschrieben wird (was ich wegen der Änderung des Marken- oder
>> Produktnamens annehme), dann ist das doch okay und es sind wirklich
>> 1.000 verschiedene Autos, die dargestellt werden. Das ist so wie bei
>> ebay, da sind die Inhalte auch ähnlich. Panini-Fußballbilder, da
>> gibt's momentan 24 Angebote, die sind sehr ähnlich, aber doch jedes
>> individuell. Ich sehe da nicht direkt das Problem.
>
> Zu wenig unterschiedlicher Content.
100% unterschiedlicher Inhalt. Navigation, Seitenfuß und -kopf etc.
zählt für mich nur sekundär zum Inhalt.
> Doch, das liegt *auch* an den Parametern bzw. deren bloßer Existenz.
> Nimm als Beispiel
>
> a.) http://www.irgendeinshop.de/custom.php?kundenid=1
>
> und
>
> b.) http://www.irgendeinshop.de/custom.php
>
> mit dem gleichen dynamisch generierten Content, nämlich eine
> personalisierte Kundenseite.
In Beispiel b finde ich keinen Verweis auf den Kunden. URL b wird eher
http://www.example.org/custom.php/1 oder
http://www.example.org/custom/1 oder
http://www.example.org/1/custom/ oder
http://1.example.org/custom oder so lauten.
Und dann kann ich wieder die 1 verändern und, wenn dasselbe Skript
dahintersteht, macht es keinen Unterschied, ob URL mit oder ohne Query
String (ggf. macht es einen bei der Subdomain),
>>>> Wenn ich unter example.org/content.html den Inhalt und unter
>>>> example.org/content.html?mode=admin die Administration des Inhalts
>>>> erreiche, ohne Paßwortschutz, ist das grob fahrlässig und keine
>>>> Gefahr, die durch den Gebrauch von Parametern in der URL entsteht.
>
> Ob man für dieses Konstrukt haftbar zu machen ist, ist noch eine andere
> Frage.
Natürlich. Das ist überhaupt keine Frage.
> example.org/admin/edit/content.html ist bei dir identisch mit
> example.org/content.html?mode=admin. Ich hatte dich so verstanden, daß
> der Parameter in dem Fall dafür sorgt, daß Daten für die Seite aus dem
> Verzeichnis /admin geholt werden.
Die Daten werden doch alle aus der Datenbank geholt, dachte ich. Wie die
URLs lauten, ist ja beliebig. Mit realen Verzeichnissen brauche ich
nicht unbedingt zu arbeiten, wenn ich eine Datenbank nutze.
Viele Grüße
Gustaf
Niels Braczek
> Niels Braczek schrieb:
>> Hinter dem durch die Itemid spezifizierten
>> Menüeintrag steckt nämlich eine sehr weit reichende
>> Konfigurationsmöglichkeit, die sehr unterschiedliche Darstellungen des
>> eigentlichen Inhalts ermöglicht.
> Ja, das Problem ist da doch, dass ich die Konfiguration auf CMS-Seite
> einstellen und nicht alle Möglichkeiten veröffentlichen will (auch wenn
> sie nicht verlinkt sind). Das zeigt für mich ganz deutlich, dass da
> jemand URLs nicht verstanden hat. Und es bestätigt meine Aussage, dass
> man sich um das URL-Design zuerst Gedanken machen muß und dass es keine
> zusätzliche, nachher überstülpbare Sache ist, sondern halt Teil des
> Grundgerüsts. Joomla 1.0.x hat noch weitere derartige unerfreuliche
> Dinge, dass es denselben Inhalt unter verschiedenen URLs veröffentlicht,
> wenn man nicht genau aufpasst.
Drehen wir den Spieß doch mal um. Welche Alternative empfiehlst du, um
verschiedene Perspektiven des (aus Datenbank-Sicht) selben Inhaltes
konfigurierbar anzubieten? Diese verschiedenen Perspektiven sollen dabei
für den Nutzer spürbar unterschiedlichen Charakter haben - zB.
Inhaltsverzeichnis einer Kategorie mit Suchfunktion vs. Auflistung der
enthaltenen Artikel mit Anreißertexten (diese Liste ist bei Weitem
unvollständig und dient nur als Beispiel). Zu beachten ist dabei, dass
nur *eine* Instanz, bspw. das Skript show.php, weiß, wie die Daten in
der Datenbank strukturiert sind und sie somit zur Darstellung
aufbereiten kann (bei Joomla wäre das nicht show.php, sondern die
Komponente "Content", die mit dem Inhalt mit der ID 12 die Funktion
"View" ausführen soll - also
index.php?option=com_content&task=view&id=12; aber das ändert nichts an
der Problemstellung).
Michael Fesser
>Drehen wir den Spieß doch mal um. Welche Alternative empfiehlst du, um
>verschiedene Perspektiven des (aus Datenbank-Sicht) selben Inhaltes
>konfigurierbar anzubieten?
Das, was für diesen Anwendungsfall als Parameter an die URL angehängt
wird, läßt sich i.d.R. auch problemlos im Pfad selbst unterbringen. Man
braucht ggf. nur etwas Kreativität, um möglichst kurze, aber dennoch
schmissige Begriffe zu haben.
>Diese verschiedenen Perspektiven sollen dabei
>für den Nutzer spürbar unterschiedlichen Charakter haben - zB.
>Inhaltsverzeichnis einer Kategorie mit Suchfunktion vs. Auflistung der
>enthaltenen Artikel mit Anreißertexten (diese Liste ist bei Weitem
>unvollständig und dient nur als Beispiel).
http://example.com/produkte/bekleidung/damen+herren
=> Artikel
http://example.com/produkte/bekleidung/damen+herren/inhalt
=> Übersicht, Suche
Oder andersrum. Analog dazu
http://example.com/produkte/bekleidung/damen+herren/1234
=> kurze Beschreibung des Artikels #1234, Preis, Bild
http://example.com/produkte/bekleidung/damen+herren/1234/details
=> ausführliche Beschreibung, ggf. mehr Bilder, Kommentare etc.
Micha
Niels Braczek
> .oO(Niels Braczek)
>>Diese verschiedenen Perspektiven sollen dabei
>>für den Nutzer spürbar unterschiedlichen Charakter haben - zB.
>>Inhaltsverzeichnis einer Kategorie mit Suchfunktion vs. Auflistung der
>>enthaltenen Artikel mit Anreißertexten (diese Liste ist bei Weitem
>>unvollständig und dient nur als Beispiel).
>
> http://example.com/produkte/bekleidung/damen+herren
> => Artikel
>
> http://example.com/produkte/bekleidung/damen+herren/inhalt
> => Übersicht, Suche
>
> Oder andersrum. Analog dazu
>
> http://example.com/produkte/bekleidung/damen+herren/1234
> => kurze Beschreibung des Artikels #1234, Preis, Bild
>
> http://example.com/produkte/bekleidung/damen+herren/1234/details
> => ausführliche Beschreibung, ggf. mehr Bilder, Kommentare etc.
Das ist doch nur Kosmetik. Das nachzubilden ist durch Einsatz von zB.
JoomSEF mit Joomla! überhaupt kein Problem (und im Übrigen empfohlen).
*Intern* kommst du damit aber auch nicht um Parameter herum. Gustaf
behauptete ja gerade, dass die Verwendung von Parametern mit fehlendem
Grundverständnis oder Nachdenken gleichzusetzen wäre. Ich sehe darin
jedoch lediglich das Weglassen von Kosmetik, das dem Administrator
erlaubt, diejenige Komponente zu nutzen, die die URLs so darstellt, wie
er es gerne hätte. Also eher ein Plus- als ein Minuspunkt.
Michael Fesser
>Das ist doch nur Kosmetik. Das nachzubilden ist durch Einsatz von zB.
>JoomSEF mit Joomla! überhaupt kein Problem (und im Übrigen empfohlen).
>*Intern* kommst du damit aber auch nicht um Parameter herum.
Jein. Manchmal brauchts schon etwas mehr Scriptaufwand als nur die
Auswertung lumpiger URL-Parameter. Nicht alles läßt sich so ohne
weiteres per mod_rewrite o.ä. von sprechenden URLs auf Parameter
abbilden. Ist dann aber natürlich auch nur eine interne Geschichte.
>Gustaf
>behauptete ja gerade, dass die Verwendung von Parametern mit fehlendem
>Grundverständnis oder Nachdenken gleichzusetzen wäre. Ich sehe darin
>jedoch lediglich das Weglassen von Kosmetik, das dem Administrator
>erlaubt, diejenige Komponente zu nutzen, die die URLs so darstellt, wie
>er es gerne hätte. Also eher ein Plus- als ein Minuspunkt.
OK.
Micha
Gustaf Mossakowski
>Gustaf Mossakowski <gus...@gmx.de> writes:
>>> "http://www.w3.org/Provider/Style/URI.html"
>> Es ist ja noch nichtmal ausschließlich unter einer URL zu erreichen.
>
> Praktisch jede Quelle hat heute unbegrenzt viele URIs:
Naja.
> http://w3.org/Provider/Style/URI
Die leitet bei mir direkt auf <http://www.w3.org/Provider/Style/URI> um,
zählt also nicht.
> http://www.w3.org/Provider/Style/URI
Die leitet nicht um, bzw. die Variante mit .html am Ende leitet nicht
auf diese URL um, die ja laut Text die bessere Variante ist.
> http://www.w3.org/%50rovider/Style/URI
Ist diese URL nicht identisch zu der darüber genannten?
> http://www.w3.org/Provider/Style/URI?a
> http://www.w3.org/Provider/Style/URI?b
Korrekterweise müsste hier dann ein 404 Not Found kommen, oder?
Viele Grüße, Gustaf.
Christoph Schneegans
>> Praktisch jede Quelle hat heute unbegrenzt viele URIs:
>
> Naja.
Doch, das stimmt. Jede Quelle hat sogar unbegrenzt viele nicht äquivalente
URIs.
>> http://www.w3.org/%50rovider/Style/URI
>
> Ist diese URL nicht identisch zu der darüber genannten?
Nicht identisch, aber äquivalent, vgl.
<http://www.textuality.com/tag/uri-comp-4.html>. Äquivalente URLs können
leicht als solche identifiziert werden, sind also unproblematisch.
>> http://www.w3.org/Provider/Style/URI?a
>> http://www.w3.org/Provider/Style/URI?b
>
> Korrekterweise müsste hier dann ein 404 Not Found kommen, oder?
IMO unbedingt. Bspw. <http://schneegans.de/?foo> oder
<http://schneegans.de/lv/?tag=de&bar> handhaben das so.
--
<http://schneegans.de/sv/> · Schema-Validator für XML
Simon Krahnke
> Ich denke nicht, dass es für eine Suchmaschine empfehlenswert ist,
> Suchergebnis-Listen zu indizieren. Macht auch kaum eine.
Welche macht es denn nicht?
mfg, simon .... l
Christoph Schneegans
> Konsequent wäre es von einer Suchmaschine, wenn sie keine Treffer
> findet, einen 404-Fehlercode zurückzugeben.
Das ist Quatsch, sorry.
> <http://www.google.de/search?q=fgjntnhortnhtrh> macht das nicht.
Diese URL bezeichnet die Ressource "Liste der Fundstellen für den Begriff
'fgjntnhortnhtrh'". Diese Ressource existiert. Es spielt keine Rolle, ob
die Liste leer ist.
Bei bspw. "http://www.example.org/page.php?id=impressum" ist das anders.
"http://www.example.org/page.php?id=fgjntnhortnhtrh" sollte 404 zurückgeben.
--
<http://schneegans.de/xp/> · text/html in application/xhtml+xml umwandeln
Alexander Schestag
Frank Müller wrote:
> Hallo Alexander,
>
>>> 2. Wenn auf jeder der 1.000 Einzelseiten ein anderes Auto beschrieben
>>> wird (was ich wegen der Änderung des Marken- oder Produktnamens
>>> annehme), dann ist das doch okay und es sind wirklich 1.000
>>> verschiedene Autos, die dargestellt werden. Das ist so wie bei ebay,
>>> da sind die Inhalte auch ähnlich. Panini-Fußballbilder, da gibt's
>>> momentan 24 Angebote, die sind sehr ähnlich, aber doch jedes
>>> individuell. Ich sehe da nicht direkt das Problem.
>> Zu wenig unterschiedlicher Content.
> Wie meinst du das jetzt?
> Auf einer Site (Autohaus) x Fahrzeuge die unterschiedlich sind
Die unterschiedlich sein mögen, aber die nicht genügend
unterschiedlichen Content liefern. Vielleicht war das Beispiel schlecht,
aber ich denke, das Prinzip ist klar: Wenn nur ein Parameter geändert
wird, kann es theoretisch sein, daß sich zwei Seiten gar nicht oder nur
durch eine Kleinigkeit unterscheiden.
>>> Ich denke nicht, dass es für eine Suchmaschine empfehlenswert ist,
>>> Suchergebnis-Listen zu indizieren. Macht auch kaum eine.
>> Das geht auch nicht, denn dann müßte die Suchmaschine ja einen
>> Suchbegriff eingeben. ;-)
> Das geht schon. Denn oft ist es ja so, dass die
> Suchseite z.B. Artikelsuche.php indiziert wird.
> Und wenn der User nichts eingibt an Suchbegriff
> wird nur per clientseitigem Begriff die Meldung ausgegeben,
> dass man einen Suchbegriff eingeben soll. Serverseitig wird
> nicht geprüft und schwupps erhält die Suchmaschine ALLE
> Artikel weil sie JavaScript nicht interpretiert. Und schon sind
> die Seiten erfasst.
Wenn die entsprechenden Bedingungen gegeben sind, mag das zutreffen, ja.
>> Doch, das liegt *auch* an den Parametern bzw. deren bloßer Existenz.
>> Nimm als Beispiel
>> a.) http://www.irgendeinshop.de/custom.php?kundenid=1
>> und
>> b.) http://www.irgendeinshop.de/custom.php
>> mit dem gleichen dynamisch generierten Content, nämlich eine
>> personalisierte Kundenseite. in Beispiel a.) ist es durch einfache
>> Parametermanipulation deutlich einfacher, eine Lücke auszunützen, die
>> darin besteht, daß durch Einsetzen einer anderen Zahl in der Variable
>> kundenid ein unautorisierter Zugriff auf fremde Kundendaten möglich
>> ist, weil diese nicht ausreichend geschützt wurden.
> Wer macht den so was heutzutage noch?
Bis vor nicht allzu langer Zeit (und das nicht zum ersten Mal!) ein
führender Telekommunikationsanbieter in Deutschland, und sie haben das
Problem trotz Meldung monatelang nicht behoben. Stattdessen wurde dem
Entdecker der Lücke mit rechtlichen Schritten gedroht. Eine ähnliche
Lücke bei einem von Reisebüros eingesetzten Webinterface wurde noch im
Dezember 2006 auf dem Chaos Communication Congress vorgestellt, nachdem
auch hier das betroffene Unternehmen nicht bereit war, die Lücke zu
schließen. Aber auch andere, weniger prominente Beispiele findest du mit
ein wenig Ausprobieren nach wie vor massenweise.
> Wenn ich durch Austausch von meiner ...kundenid=1 zu kundenid=2
> fremde Kundendaten bearbeiten könnte, würde ich sofort
> den Provider wechseln.
Was kann der Provider dafür (es sei denn, es sind Providerseiten)? Den
Programmierer der Seiten mußt du treten.
> Da muß zwingend eine Anmeldung kommen mit der ich mich über Username
> / Passwort / Kundennummer oder was auch immer identifizieren muss,
> damit ich die Daten bearbeiten kann.
<Loriot>Ach?!</Loriot>
> Ich glaube da lebst du in der Steinzeit, dass so etwas noch möglich ist.
Und ich glaube, ehe du mich verunglimpfst, solltest du deine Kenntnisse
auffrischen. Die Lektüre einschlägiger Literatur wie der Datenschleuder
oder anderer Publikationen, in denen derartige Löcher in den
Webanwendungen prominenter Unternehmen mit schöner Regelmäßigkeit
veröffentlicht werden, mag da helfen.
>> In Beispiel b.)
>> muß ich mich mehr anstrengen, um die gleiche Lücke auszunutzen. Nein,
>> ich will damit nicht sagen, daß b.) sicherer ist. Aber a.) macht es
>> einem
>> Angreifer *noch* leichter, weil ihm die entscheidenden Variablen in
>> den URL-Parametern gleich mitgeliefert werden.
> Sehe ich nicht so, denn beide Varianten können gleich sicher
> umgesetzt werden.
<Loriot>Ach?!</Loriot>. Ich sprach von dem Fall, daß es NICHT sicher
umgesetzt wird, was immer noch allzu oft der Fall ist! Wenn dann
Parameter fehlen, ist das zwar Security by Obscurity, aber doch ein
kleines bißchen schwerer auszuhebeln als die einfache Veränderung eines
einzigen Parameters.
> Wenn sie falsch umgesetzt werden, dann
> sind ich auch gleich unsicher.
Theoretisch ja. Praktisch liefern in diesem Falle Parameter zusätzliche
Informationen, die ein Ausnützen der Lücke vereinfachen.
> So etwas regelt man vernünftigerweise über die Zugriffsrechte auf die Seiten
> unabhängig davon wie sie aufgerufen werden / werden können.
<Loriot>Ach?!</Loriot>
> Also das jetzt an Parametern in der URL festzumachen ist
> meiner persönlichen Meinung nach absoluter Quatsch, da
> müssen andere Sicherheitsmechanismen greifen.
[ ] Du hast mich verstanden.
Es ging mir um unsichere Umsetzungen, nicht um sichere. Da ist es in der
Tat egal.
Alex
Gustaf Mossakowski
> Michael Fesser schrieb:
>> .oO(Niels Braczek)
>>> Diese verschiedenen Perspektiven sollen dabei für den Nutzer
>>> spürbar unterschiedlichen Charakter haben - zB. Inhaltsverzeichnis
>>> einer Kategorie mit Suchfunktion vs. Auflistung der enthaltenen
>>> Artikel mit Anreißertexten (diese Liste ist bei Weitem
>>> unvollständig und dient nur als Beispiel).
>>
>> http://example.com/produkte/bekleidung/damen+herren
>> => Artikel
>>
>> http://example.com/produkte/bekleidung/damen+herren/inhalt
>> => Übersicht, Suche
>>
>> Oder andersrum. Analog dazu
>>
>> http://example.com/produkte/bekleidung/damen+herren/1234
>> => kurze Beschreibung des Artikels #1234, Preis, Bild
>>
>> http://example.com/produkte/bekleidung/damen+herren/1234/details
>> => ausführliche Beschreibung, ggf. mehr Bilder, Kommentare etc.
Genau, so könnte man dann auch, wenn man für ein Produkt keine
Detailseite braucht, aus welchen Gründen auch immer, diese URL weglassen
bzw. das CMS so konfigurieren, dass es hier einen 404-Fehler ausgibt.
> Das ist doch nur Kosmetik. Das nachzubilden ist durch Einsatz von zB.
> JoomSEF mit Joomla! überhaupt kein Problem (und im Übrigen empfohlen).
Das ist keine Kosmetik. Ich frage mich, warum ich überhaupt den Schritt
gehen muß, diese komischen URLs in vernünftige umzuschreiben, warum ich
nicht gleich vernünftige URLs nutzen kann. Momentan ist es doch so, dass
ich durch URL-Manipulation alle möglichen Darstellungsmethoden
standardmäßig abfragen kann, ohne dass ich als Autor diese einfach
ausschließen kann. Ich will nicht ausschließen, dass ich mich vor
anderthalb Jahren da nicht genug bei Joomla! umgesehen habe, um
herauszufinden, wie das geht.
> *Intern* kommst du damit aber auch nicht um Parameter herum.
Parameter sind eine Möglichkeit. Man kann auch alle URLs oder ein
vorbestimmtes Set von URLs (z. B. bestimmte Pfade oder URLs, die mit
regulären Ausdrücken übereinstimmen) direkt an ein Skript weitergeben,
dass dann anhand der URL Inhalte zurückgibt. Dafür braucht man keine
Parameter und auch kein mod_rewrite.
> Gustaf
> behauptete ja gerade, dass die Verwendung von Parametern mit fehlendem
> Grundverständnis oder Nachdenken gleichzusetzen wäre.
Na, so ausschließlich habe ich das nicht behauptet. Parameter können
durchaus an bestimmten Stellen sinnvoll sein, z. B. bei Suchergebnissen,
z. B. bei Daten, die über mehrere Seiten verteilt sind zum Blättern, bei
Formularoperationen usw.
> Ich sehe darin
> jedoch lediglich das Weglassen von Kosmetik, das dem Administrator
> erlaubt, diejenige Komponente zu nutzen, die die URLs so darstellt, wie
> er es gerne hätte. Also eher ein Plus- als ein Minuspunkt.
Nicht jedes CMS arbeitet mit Komponenten. Eines der Hauptargumente
sollte doch sein, dass URLs zumindest nicht unnötig geändert werden (sie
müssen ja nicht gleich 200 Jahre halten, wie Christoph schrieb), und das
wird schwierig, wenn man
example.com/index.php?option=com_content&task=view&id=12 oder ähnliches
verwendet. Ich gebe dir ja Recht, dass es bei Joomla! Kosmetik ist, wenn
man die URLs schöner macht. Andere CMS arbeiten direkt mit den URLs, da
kann man frei definieren, was bei welcher URL auftauchen soll, da ist
das keine Kosmetik. Und die sind, was das URL-Design angeht, deutlich
flexibler.
Viele Grüße
Gustaf
Gustaf Mossakowski
>> Ich denke nicht, dass es für eine Suchmaschine empfehlenswert ist,
>> Suchergebnis-Listen zu indizieren. Macht auch kaum eine.
>
> Welche macht es denn nicht?
Ja, zumindest alle großen machen das nicht. Kann aber auch sein, dass
die Suchmaschinenbetreiber die Suchergebnisse per robots.txt sperren.
Ich habe zumindest noch nie eine Suchergebnisliste von Yahoo! bei Google
gefunden, oder von MSN etc.
Viele Grüße
Gustaf
Gustaf Mossakowski
>> Konsequent wäre es von einer Suchmaschine, wenn sie keine Treffer
>> findet, einen 404-Fehlercode zurückzugeben.
>
> Das ist Quatsch, sorry.
Na, Quatsch würde ich nicht direkt sagen, war ein Gedanke, ...
>> <http://www.google.de/search?q=fgjntnhortnhtrh> macht das nicht.
>
> Diese URL bezeichnet die Ressource "Liste der Fundstellen für den Begriff
> 'fgjntnhortnhtrh'". Diese Ressource existiert. Es spielt keine Rolle, ob
> die Liste leer ist.
... aber du hast mich mit deiner Argumentation überzeugt.
Viele Grüße
gustaf
Christoph Schneegans
> Eines der Hauptargumente sollte doch sein, dass URLs zumindest nicht unnötig
> geändert werden (sie müssen ja nicht gleich 200 Jahre halten, wie Christoph
> schrieb),
Ich habe durchaus nicht geschrieben, daß sie das müssen. Ich habe in
<news:5fc2f7F...@mid.individual.net> vielmehr geschrieben, daß es
praktisch unmöglich ist, sprechende URLs zu konstruieren, die 200 Jahre
lang halten.
--
<http://schneegans.de/web/kanonische-adressen/> · URLs richtig verwenden
Simon Krahnke
Aber Google-Groups bei Google, Ergebnisse von kleinen Suchmaschinen
findet man auch oft.
mfg, simon .... l
Gustaf Mossakowski
>> Eines der Hauptargumente sollte doch sein, dass URLs zumindest nicht
>> unnötig geändert werden (sie müssen ja nicht gleich 200 Jahre
>> halten, wie Christoph schrieb),
>
> Ich habe durchaus nicht geschrieben, daß sie das müssen. Ich habe in
> <news:5fc2f7F...@mid.individual.net> vielmehr geschrieben, daß es
> praktisch unmöglich ist, sprechende URLs zu konstruieren, die 200 Jahre
> lang halten.
Ist mir bewußt. Streiche »schrieb«, setze »beschrieb«, dann ist's
präziser, dass es nicht deine Auffassung ist.
Ob es praktisch unmöglich ist, ist reine Spekulation, aber es kann
durchaus passieren. Manche Sachen überstehen die Zeiten. Der
10-Tage-Kalender hat sich nicht durchgesetzt. Goethes Texte können wir
wie auch Bachs Noten noch im Original lesen und verstehen. Aber das
führt letztlich zu weit.
Viele Grüße
Gustaf
Niels Braczek
> Niels Braczek schrieb:
>> Das ist doch nur Kosmetik. Das nachzubilden ist durch Einsatz von zB.
>> JoomSEF mit Joomla! überhaupt kein Problem (und im Übrigen empfohlen).
>
> Das ist keine Kosmetik. Ich frage mich, warum ich überhaupt den Schritt
> gehen muß, diese komischen URLs in vernünftige umzuschreiben, warum ich
> nicht gleich vernünftige URLs nutzen kann. Momentan ist es doch so, dass
> ich durch URL-Manipulation alle möglichen Darstellungsmethoden
> standardmäßig abfragen kann, ohne dass ich als Autor diese einfach
> ausschließen kann. Ich will nicht ausschließen, dass ich mich vor
> anderthalb Jahren da nicht genug bei Joomla! umgesehen habe, um
> herauszufinden, wie das geht.
Du vermischst - glaube ich - zwei Ebenen. Der Joomla!-Kern verwendet
einen URL, wie er sich durch technische Erfordernisse des Systems
ergibt. Es gibt dazu keine Alternative. Das System braucht nunmal die ID
des darzustellenden Inhalts und eine Anweisung, was mit diesem Inhalt zu
machen ist.
>> *Intern* kommst du damit aber auch nicht um Parameter herum.
>
> Parameter sind eine Möglichkeit. Man kann auch alle URLs oder ein
> vorbestimmtes Set von URLs (z. B. bestimmte Pfade oder URLs, die mit
> regulären Ausdrücken übereinstimmen) direkt an ein Skript weitergeben,
> dass dann anhand der URL Inhalte zurückgibt. Dafür braucht man keine
> Parameter und auch kein mod_rewrite.
Damit verlagerst du nur die Umrechnung von Wörten in IDs in das CMS und
schränkst dadurch die Möglichkeiten ein, die sich durch freie Wahl des
verwendeten Werkzeugs ergeben würden.
>> Ich sehe darin
>> jedoch lediglich das Weglassen von Kosmetik, das dem Administrator
>> erlaubt, diejenige Komponente zu nutzen, die die URLs so darstellt, wie
>> er es gerne hätte. Also eher ein Plus- als ein Minuspunkt.
>
> Nicht jedes CMS arbeitet mit Komponenten. Eines der Hauptargumente
> sollte doch sein, dass URLs zumindest nicht unnötig geändert werden (sie
> müssen ja nicht gleich 200 Jahre halten, wie Christoph schrieb), und das
> wird schwierig, wenn man
> example.com/index.php?option=com_content&task=view&id=12 oder ähnliches
> verwendet.
Gerade bei diesem Beispiel ist das sehr einfach. Es ist definiert, was
wo mit wem zu machen ist. Solange diese Ressource existiert, muss daran
nichts geändert werden. Mit Wörten kann dir eher passieren, dass
geändert werden muss, weil die einem Bedeutungswandel unterliegen können.
> Ich gebe dir ja Recht, dass es bei Joomla! Kosmetik ist, wenn
> man die URLs schöner macht. Andere CMS arbeiten direkt mit den URLs, da
> kann man frei definieren, was bei welcher URL auftauchen soll, da ist
> das keine Kosmetik. Und die sind, was das URL-Design angeht, deutlich
> flexibler.
Da irrst du. Nur weil du den Umsetzungprozess weder siehst noch
beeinflussen kannst, heißt das nicht, dass er nicht da ist. Flexibler
als der Joomla!-Ansatz ist, geht es nicht.
Gustaf Mossakowski
> Du vermischst - glaube ich - zwei Ebenen. Der Joomla!-Kern verwendet
> einen URL, wie er sich durch technische Erfordernisse des Systems
> ergibt. Es gibt dazu keine Alternative. Das System braucht nunmal die ID
> des darzustellenden Inhalts und eine Anweisung, was mit diesem Inhalt zu
> machen ist.
Ja, das stimmt. Aber das ist absolut Joomla!-spezifisch. Wenn man nur im
Rahmen von Joomla! denkt, gibt es dazu keine Alternative. Es gibt aber
auch noch tausend andere CMS, die mit den Joomla!-URLs nicht zurecht
kommen. Diese kommen aber, wenn sie gut sind, mit sprechenden URLs
zurecht, weil sie eben nicht versuchen, ihre interne Programmlogik auf
die URLs umzusetzen, sondern freie URLs zulassen. Das bedeutet für mich
nicht, dass man totale Anarchie bei den URLs unterstützen sollte (wobei
das letztlich auch kein Problem ist, aber nicht unbedingt wünschenswert).
>> Parameter sind eine Möglichkeit. Man kann auch alle URLs oder ein
>> vorbestimmtes Set von URLs (z. B. bestimmte Pfade oder URLs, die mit
>> regulären Ausdrücken übereinstimmen) direkt an ein Skript
>> weitergeben, dass dann anhand der URL Inhalte zurückgibt. Dafür
>> braucht man keine Parameter und auch kein mod_rewrite.
>
> Damit verlagerst du nur die Umrechnung von Wörten in IDs in das CMS und
> schränkst dadurch die Möglichkeiten ein, die sich durch freie Wahl des
> verwendeten Werkzeugs ergeben würden.
Verstehe ich das richtig, für dich besteht eine ideale URL-Struktur aus
Datenbank-IDs?
>> [example.com/index.php?option=com_content&task=view&id=12]
>
> Gerade bei diesem Beispiel ist das sehr einfach. Es ist definiert, was
> wo mit wem zu machen ist. Solange diese Ressource existiert, muss daran
> nichts geändert werden. Mit Wörten kann dir eher passieren, dass
> geändert werden muss, weil die einem Bedeutungswandel unterliegen können.
Solange die Ressource existiert, hat man auch mit Wörtern kein Problem.
Sobald du aber das zugrundeliegende System änderst (weil du ein anderes
System nutzen willst, weil du statische Webseiten nutzen willst, weil
das benutzte System seine URL-Syntax ändert), wird es sehr schwierig.
Mit Wörtern und Daten usw. habe ich das Problem vielleicht auch, in
zwanzig, fünfzig oder hundert Jahren. Aber das sind Zeiträume, um die
ich mir kaum Sorgen mache. Wenn ich eine Zeitschrift veröffentliche und
die Inhalte unter /zeitschriftname/jahr/monat/ veröffentliche, werde ich
kaum Probleme bekommen, auch nicht, wenn die Zeitschrift eingestellt
wird, dann läuft der Bereich mit URLs halt aus.
> Da irrst du. Nur weil du den Umsetzungprozess weder siehst noch
> beeinflussen kannst, heißt das nicht, dass er nicht da ist. Flexibler
> als der Joomla!-Ansatz ist, geht es nicht.
Wenn ich den Umsetzungsprozess nicht beeinflussen kann, wie kann er dann
flexibel sein?
Viele Grüße
Gustaf
Niels Braczek
> Niels Braczek schrieb:
>
>> Du vermischst - glaube ich - zwei Ebenen. Der Joomla!-Kern verwendet
>> einen URL, wie er sich durch technische Erfordernisse des Systems
>> ergibt. Es gibt dazu keine Alternative. Das System braucht nunmal die ID
>> des darzustellenden Inhalts und eine Anweisung, was mit diesem Inhalt zu
>> machen ist.
>
> Ja, das stimmt. Aber das ist absolut Joomla!-spezifisch. Wenn man nur im
> Rahmen von Joomla! denkt, gibt es dazu keine Alternative. Es gibt aber
> auch noch tausend andere CMS, die mit den Joomla!-URLs nicht zurecht
> kommen. Diese kommen aber, wenn sie gut sind, mit sprechenden URLs
> zurecht, weil sie eben nicht versuchen, ihre interne Programmlogik auf
> die URLs umzusetzen, sondern freie URLs zulassen.
*Jedes* CMS braucht ein Mapping URL -> Inhalt. Joomla!-spezifisch ist
hier nur, dass du die Wahl hast, welches System du dafür einsetzen
willst (und natürlich auch die Wahl, direkt mit den technischen URLs zu
arbeiten).
>> Damit verlagerst du nur die Umrechnung von Wörten in IDs in das CMS und
>> schränkst dadurch die Möglichkeiten ein, die sich durch freie Wahl des
>> verwendeten Werkzeugs ergeben würden.
>
> Verstehe ich das richtig, für dich besteht eine ideale URL-Struktur aus
> Datenbank-IDs?
Nein, da verstehst du mich miss. Ich wehre mich hier nur gegen deinen
Vorwurf, man hätte nicht nachgedacht, wenn man Parameter benutzt. Ich
bevorzuge ebenfalls sprechende URLs, wie du an meiner Site (die zweite
in meiner Sig.) sehen kannst.
> Wenn ich eine Zeitschrift veröffentliche und
> die Inhalte unter /zeitschriftname/jahr/monat/ veröffentliche, werde ich
> kaum Probleme bekommen
Schönes Beispiel für meine Behauptung. Das System, dass diese URL
verwendet, bildet intern /zeitschriftname/jahr/monat/ auf drei Variablen
ab. Das meinte ich damit, dass jedes System mit Funktionalität Parameter
*braucht*. Sie sind hier nur hübsch verpackt, was ich als Kosmetik
bezeichnete.
>> Da irrst du. Nur weil du den Umsetzungprozess weder siehst noch
>> beeinflussen kannst, heißt das nicht, dass er nicht da ist. Flexibler
>> als der Joomla!-Ansatz ist, geht es nicht.
>
> Wenn ich den Umsetzungsprozess nicht beeinflussen kann, wie kann er dann
> flexibel sein?
Bei Joomla! kannst du das ja beeinflussen. Und zwar beliebig. Bei den
Systemen, die von vornherein "schöne" URLs liefern, hast du
wahrscheinlich wenig bis keinen Einfluss auf deren Struktur.
Gustaf Mossakowski
> Gustaf Mossakowski schrieb:
>> Niels Braczek schrieb:
>>> Du vermischst - glaube ich - zwei Ebenen. Der Joomla!-Kern
>>> verwendet einen URL, wie er sich durch technische Erfordernisse des
>>> Systems ergibt. Es gibt dazu keine Alternative. Das System braucht
>>> nunmal die ID des darzustellenden Inhalts und eine Anweisung, was
>>> mit diesem Inhalt zu machen ist.
>>
>> Ja, das stimmt. Aber das ist absolut Joomla!-spezifisch. Wenn man
>> nur im Rahmen von Joomla! denkt, gibt es dazu keine Alternative. Es
>> gibt aber auch noch tausend andere CMS, die mit den Joomla!-URLs
>> nicht zurecht kommen. Diese kommen aber, wenn sie gut sind, mit
>> sprechenden URLs zurecht, weil sie eben nicht versuchen, ihre
>> interne Programmlogik auf die URLs umzusetzen, sondern freie URLs
>> zulassen.
>
> *Jedes* CMS braucht ein Mapping URL -> Inhalt.
Klar, das geht ja auch gar nicht anders. Ich bezog meinen Kommentar auf
den Satz: »Der Joomla!-Kern verwendet einen URL, wie er sich durch
technische Erfordernisse des Systems ergibt.« Ich hatte das so
verstanden, dass Joomla! URLs wie die Beispiel-URL mit
»/index.php?option=com_content&task=view&id=12« benötigt, auch wenn man
nachher kosmetisch umschreibt.
> Joomla!-spezifisch ist
> hier nur, dass du die Wahl hast, welches System du dafür einsetzen
> willst (und natürlich auch die Wahl, direkt mit den technischen URLs zu
> arbeiten).
D. h., ich habe die Wahl, wie ich die URLs umschreiben lasse? Die
vollkommen freie Wahl? Mal hier ein paar Beispiel-URLs von früheren
Projekten von mir:
Terminkalender und Nachrichten:
/aktuell/ - Aktuelle Termine und Nachrichten
/aktuell/2005ws/ - Termine aus dem Wintersemester 2005/06
/aktuell/2005ss/ - Termine aus dem Sommersemester 2005 (weitere URLs
beliebig zusammenbaubar, wenn es nichts in dem Semester gibt, wird ein
404 zurückgegeben)
/aktuell/archiv/ - Archiv mit Terminen und Nachrichten als Übersicht pro
Semester
/aktuell/nachrichten/ - Übersicht der Nachrichten
/aktuell/nachrichten/2007-01-11/ - Nachricht
Ligensystem für Sport:
/ligen/ - gibt Übersicht aller Ligen auf der Site aus
/ligen/stadtliga/ - gibt Übersicht der aktuellen Runde der Stadtliga und
eine Übersicht aller bisherigen Saisons der Stadtliga auf der Site aus
/ligen/stadtliga/2005/ - gibt Übersicht der Saison 2004/05 der Stadtliga
aus
/ligen/stadtliga/2005/1/ - 1. Spieltag Saison 2004/05
/ligen/stadtliga/2005/vereinx-1/ - Termine und Mannschaftsaufstellung
VereinX, 1. Mannschaft, Saison 2004/05
/ligen/stadtliga/2005/vereiny-1/ - dito, Verein Y
/ligen/bundesliga/2007/9/ - Bundesliga 2006/07, 9. Spieltag
und andere, je nach Erfordernis der Aufgabe. Mir ist dabei wichtig, dass
ich nicht für jede Saison z. B. eine neue Seite anlegen muß, sondern
dass das CMS selber erkennt, was in der Datenbank steht. Das ist ja der
Sinn eines CMS.
>>> Damit verlagerst du nur die Umrechnung von Wörten in IDs in das CMS
>>> und schränkst dadurch die Möglichkeiten ein, die sich durch freie
>>> Wahl des verwendeten Werkzeugs ergeben würden.
>>
>> Verstehe ich das richtig, für dich besteht eine ideale URL-Struktur
>> aus Datenbank-IDs?
>
> Nein, da verstehst du mich miss. Ich wehre mich hier nur gegen deinen
> Vorwurf, man hätte nicht nachgedacht, wenn man Parameter benutzt. Ich
> bevorzuge ebenfalls sprechende URLs, wie du an meiner Site (die zweite
> in meiner Sig.) sehen kannst.
Aber inwiefern schränke ich denn die Möglichkeiten ein? Oder meinst du
damit, dass ich nicht mehr die Listenansicht, die Blogansicht etc. für
denselben Inhalt nutzen kann? Wenn du das meintest, sähe ich das eher
als Vorteil, da ich ja auf Anbieterseite entscheiden will, wie der
Besucher die Seiten sieht (das schließt nicht aus, dass es für Bereiche
auch unterschiedliche Ansichten wie z. B. RSS-Feeds gibt).
Ich habe mir deine Site angeschaut. Die URLs bei der Suche sehen noch
stark nach Joomla! aus. Wieso kommt man bei »/e-commerce/« auf
»/e-commerce/shops/2.html« und nicht auf »/e-commerce/shops/« (404)?
Wenn ich auf »ungefähre Kosten« klicke, unter Webdesign, passiert nix.
Schade ;-) Das ist doch immer mit das Interessanteste ... Da sind noch
ein paar kleine Fehler drin, falls Interesse besteht, schreibe ich die
gerne per Mail, gehört ja aber hier nicht in die Diskussion.
>> Wenn ich eine Zeitschrift veröffentliche und die Inhalte unter
>> /zeitschriftname/jahr/monat/ veröffentliche, werde ich kaum Probleme
>> bekommen
>
> Schönes Beispiel für meine Behauptung. Das System, dass diese URL
> verwendet, bildet intern /zeitschriftname/jahr/monat/ auf drei Variablen
> ab. Das meinte ich damit, dass jedes System mit Funktionalität Parameter
> *braucht*. Sie sind hier nur hübsch verpackt, was ich als Kosmetik
> bezeichnete.
Nein, diese Parameter sind nicht verpackt. Wobei ich bei Parameter
ursprünglich von Query Strings ausging, da Alex in seinen Postings das
gleichsetzte. Diese Parameter werden 1:1 an die Datenbank übergeben
(natürlich nach vorheriger Prüfung). Z. B.
SELECT titel, inhalt
FROM artikel
LEFT JOIN zeitschriften USING (zeitschrift_id)
WHERE zeitschrift = "zeitschriftname"
AND erscheinungsjahr = "jahr"
AND erscheinungsmonat = "monat"
oder so ähnlich. In der Datentabelle mit den Webseiten steht unter der
URL /zeitschriftenname* ein Verweis auf das Modul drin, dass diese Query
aufruft. Keinerlei Kosmetik, alles harte Daten.
> Bei Joomla! kannst du das ja beeinflussen. Und zwar beliebig. Bei den
> Systemen, die von vornherein "schöne" URLs liefern, hast du
> wahrscheinlich wenig bis keinen Einfluss auf deren Struktur.
Bei speziellen Seiten wie dem Beispiel mit den Zeitschriften oben gebe
ich dir recht, da muß ich ein Skript umschreiben, wenn ich statt Monat
z. B. die Nummer der Ausgabe abbilden möchte. Das geht (noch?) nicht
direkt über das CMS. Aber es ist nur eine einzelne Funktion, die recht
einfach ist.
Viele Grüße
Gustaf
Niels Braczek
> Niels Braczek schrieb:
> Klar, das geht ja auch gar nicht anders. Ich bezog meinen Kommentar auf
> den Satz: »Der Joomla!-Kern verwendet einen URL, wie er sich durch
> technische Erfordernisse des Systems ergibt.« Ich hatte das so
> verstanden, dass Joomla! URLs wie die Beispiel-URL mit
> »/index.php?option=com_content&task=view&id=12« benötigt, auch wenn man
> nachher kosmetisch umschreibt.
Joomla! braucht die Information, dass die Komponente "Content"
(com_content) die Seite 12 anzeigen (view) soll.
>> Joomla!-spezifisch ist
>> hier nur, dass du die Wahl hast, welches System du dafür einsetzen
>> willst (und natürlich auch die Wahl, direkt mit den technischen URLs zu
>> arbeiten).
>
> D. h., ich habe die Wahl, wie ich die URLs umschreiben lasse? Die
> vollkommen freie Wahl? Mal hier ein paar Beispiel-URLs von früheren
> Projekten von mir:
> [...]
Überhaupt kein Problem.
> und andere, je nach Erfordernis der Aufgabe. Mir ist dabei wichtig, dass
> ich nicht für jede Saison z. B. eine neue Seite anlegen muß, sondern
> dass das CMS selber erkennt, was in der Datenbank steht. Das ist ja der
> Sinn eines CMS.
Je nach System hinterlegt man komponentenweise Regeln (in PHP) zur
Umsetzung "sprechender URL" <-> "technischer URL". Für die meisten
Komponenten gibt es diese Umsetzungsregeln bereits fertig.
>>>> Damit verlagerst du nur die Umrechnung von Wörten in IDs in das CMS
>>>> und schränkst dadurch die Möglichkeiten ein, die sich durch freie
>>>> Wahl des verwendeten Werkzeugs ergeben würden.
> Aber inwiefern schränke ich denn die Möglichkeiten ein?
Wenn die URL-Generierung nicht einstellbar ist, musst du nehmen, was
kommt. Bei einem offenen System wie Joomla! hast du völlig freie Hand
bei der URL-Gestaltung.
> Oder meinst du
> damit, dass ich nicht mehr die Listenansicht, die Blogansicht etc. für
> denselben Inhalt nutzen kann? Wenn du das meintest, sähe ich das eher
> als Vorteil, da ich ja auf Anbieterseite entscheiden will, wie der
> Besucher die Seiten sieht (das schließt nicht aus, dass es für Bereiche
> auch unterschiedliche Ansichten wie z. B. RSS-Feeds gibt).
Das wird auch auf Anbieter-Seite entschieden. Es besteht aber die
Möglichkeit, den selben Inhalt in verschiedenen Perspektiven anzubieten.
Oft hat man sogar dieselbe Perspektive zweimal, zB. "Links" oder
"Impressum" im Service-Menü *und* in der normalen Navigation. Dann
benötigt man die Itemid, um festzustellen, welcher Menüpunkt
hervorgehoben werden soll.
> Ich habe mir deine Site angeschaut. Die URLs bei der Suche sehen noch
> stark nach Joomla! aus. Wieso kommt man bei »/e-commerce/« auf
> »/e-commerce/shops/2.html« und nicht auf »/e-commerce/shops/« (404)?
Das ist ein Bug in der aktuellen SEF ("search engine friendly) Komponente.
> Wenn ich auf »ungefähre Kosten« klicke, unter Webdesign, passiert nix.
> Schade ;-) Das ist doch immer mit das Interessanteste ... Da sind noch
> ein paar kleine Fehler drin, falls Interesse besteht, schreibe ich die
> gerne per Mail, gehört ja aber hier nicht in die Diskussion.
Das muss ich mir in der Tat mal genauer ansehen. Da stimmt was nicht
:-(. Schick mir bitte diese Mail...
>> Schönes Beispiel für meine Behauptung. Das System, dass diese URL
>> verwendet, bildet intern /zeitschriftname/jahr/monat/ auf drei Variablen
>> ab. Das meinte ich damit, dass jedes System mit Funktionalität Parameter
>> *braucht*. Sie sind hier nur hübsch verpackt, was ich als Kosmetik
>> bezeichnete.
>
> Nein, diese Parameter sind nicht verpackt. Wobei ich bei Parameter
> ursprünglich von Query Strings ausging, da Alex in seinen Postings das
> gleichsetzte. Diese Parameter werden 1:1 an die Datenbank übergeben
Der einzige Unterschied ist doch, dass die Zuordnung der Parameter über
ihre Position und nicht über den Namen erfolgt. Sie sind deshalb
verpackt, weil die Information verdichtet ist.
> SELECT titel, inhalt
> FROM artikel
> LEFT JOIN zeitschriften USING (zeitschrift_id)
> WHERE zeitschrift = "zeitschriftname"
> AND erscheinungsjahr = "jahr"
> AND erscheinungsmonat = "monat"
>
> oder so ähnlich. In der Datentabelle mit den Webseiten steht unter der
> URL /zeitschriftenname* ein Verweis auf das Modul drin, dass diese Query
> aufruft. Keinerlei Kosmetik, alles harte Daten.
Du musst die Parameter aus dem URL extrahieren. Darum kommst du nicht
herum. Außerdem musst du mittels mod_rewrite auf den Dispatcher
umleiten. *Kein* System kann den URL
example.com/zeitschriftname/jahr/monat/ *direkt* verarbeiten. Dazu
müsste nämlich in $root/zeitschriftname/jahr/monat/ ein Skript liegen.
>> Bei Joomla! kannst du das ja beeinflussen. Und zwar beliebig. Bei den
>> Systemen, die von vornherein "schöne" URLs liefern, hast du
>> wahrscheinlich wenig bis keinen Einfluss auf deren Struktur.
>
> Bei speziellen Seiten wie dem Beispiel mit den Zeitschriften oben gebe
> ich dir recht, da muß ich ein Skript umschreiben, wenn ich statt Monat
> z. B. die Nummer der Ausgabe abbilden möchte. Das geht (noch?) nicht
> direkt über das CMS. Aber es ist nur eine einzelne Funktion, die recht
> einfach ist.
Das ist ja das Schöne: Es ist praktisch immer so einfach. Wenn es dafür
wie bei Joomla! eine Schnittstelle gibt.
Gustaf Mossakowski
>> Ich bezog meinen Kommentar
>> auf den Satz: »Der Joomla!-Kern verwendet einen URL, wie er sich
>> durch technische Erfordernisse des Systems ergibt.« Ich hatte das so
>> verstanden, dass Joomla! URLs wie die Beispiel-URL mit
>> »/index.php?option=com_content&task=view&id=12« benötigt, auch wenn
>> man nachher kosmetisch umschreibt.
>
> Joomla! braucht die Information, dass die Komponente "Content"
> (com_content) die Seite 12 anzeigen (view) soll.
Dann hatte ich das ja richtig verstanden. Diese Logik (welche
Komponente, was passiert damit) würde ich direkt in der Datenbank oder
dem CMS dem Inhalt zuweisen, nicht über die URL bestimmen. »view« ist
vermutlich sowieso Standard. Ich würde send-a-friend und pdf und
soweiter dann an die »normale« URL hintenanhängen, evtl. als Query
String.
> Wenn die URL-Generierung nicht einstellbar ist, musst du nehmen, was
> kommt. Bei einem offenen System wie Joomla! hast du völlig freie Hand
> bei der URL-Gestaltung.
> [...]
> [Reihenfolge des Textes umgestellt]
> [...]
>> Ich habe mir deine Site angeschaut. Die URLs bei der Suche sehen noch
>> stark nach Joomla! aus. Wieso kommt man bei »/e-commerce/« auf
>> »/e-commerce/shops/2.html« und nicht auf »/e-commerce/shops/« (404)?
>
> Das ist ein Bug in der aktuellen SEF ("search engine friendly) Komponente.
Also hat man doch nicht absolut freie Hand. Zumindest jetzt noch nicht.
Das ist für Websites, die Jahre bestehen und auf ein CMS wechseln, aus
meiner Sicht nicht zufriedenstellend. Da sollen alle alten Inhalte, wenn
möglich und sinnvoll, weiter unter der alten URL erreichbar sein.
> Es besteht aber die
> Möglichkeit, den selben Inhalt in verschiedenen Perspektiven anzubieten.
> Oft hat man sogar dieselbe Perspektive zweimal, zB. "Links" oder
> "Impressum" im Service-Menü *und* in der normalen Navigation. Dann
> benötigt man die Itemid, um festzustellen, welcher Menüpunkt
> hervorgehoben werden soll.
Das fand ich bei Joomla! eher verwirrend. Normale Navigation könnte
sowas am linken Rand sein und das Service-Menü dann z. B. eine Fußzeile?
Auf der Seite /impressum/ würde ich dann »Impressum« sowohl in der
Fußzeile als auch im Service-Menü fett und aktiviert darstellen, ohne
Link auf sich selbst. Das scheint aber nicht standardmäßig vorgesehen zu
sein, auf deiner Seite verlinken die Seiten sich selbst.
>> Wenn ich auf »ungefähre Kosten« klicke, unter Webdesign, passiert
>> nix. Schade ;-) Das ist doch immer mit das Interessanteste ... Da
>> sind noch ein paar kleine Fehler drin, falls Interesse besteht,
>> schreibe ich die gerne per Mail, gehört ja aber hier nicht in die
>> Diskussion.
>
> Das muss ich mir in der Tat mal genauer ansehen. Da stimmt was nicht
> :-(. Schick mir bitte diese Mail...
Habe ich gestern verschickt.
>>> Schönes Beispiel für meine Behauptung. Das System, dass diese URL
>>> verwendet, bildet intern /zeitschriftname/jahr/monat/ auf drei
>>> Variablen ab. Das meinte ich damit, dass jedes System mit
>>> Funktionalität Parameter *braucht*. Sie sind hier nur hübsch
>>> verpackt, was ich als Kosmetik bezeichnete.
>>
>> Nein, diese Parameter sind nicht verpackt. Wobei ich bei Parameter
>> ursprünglich von Query Strings ausging, da Alex in seinen Postings
>> das gleichsetzte. Diese Parameter werden 1:1 an die Datenbank
>> übergeben
>
> Der einzige Unterschied ist doch, dass die Zuordnung der Parameter über
> ihre Position und nicht über den Namen erfolgt. Sie sind deshalb
> verpackt, weil die Information verdichtet ist.
Verdichtete Information ist aber doch keine Kosmetik. Nimm einen Text
als Beispiel. Wenn ich dasselbe in einem Buch mit 600 Seiten auch in
einem Buch mit 40 Seiten sagen kann, dann ist es in 99% der Fälle
besser, das ganze auf 40 Seiten zu verfassen: mehr Leute werden es
lesen, es kostet weniger im Druck und meist kommt die Botschaft auch
noch klarer rüber.
www.bsds.de statt 212.227.245.92 ist auch nur Kosmetik, trotzdem bietet
es Vorteile: leichter zu merken, und, ähnlich CMS-URLs, bei einem
Serverumzug muß man sich keine neue Adresse merken.
Ich glaube, dass das ein Kernpunkt in unserer Diskussion ist. Meine
Aussage, dass sprechende URLs Teil des Gerüsts des WWW sind, war ja
ursprünglich der Auslöser. Du betrachtest es eher als technisches, ich
eher als soziales Phänomen, so mein Eindruck. Bitte korrigiere mich,
wenn ich da falsch liege.
> Du musst die Parameter aus dem URL extrahieren. Darum kommst du nicht
> herum. Außerdem musst du mittels mod_rewrite auf den Dispatcher
> umleiten. *Kein* System kann den URL
> example.com/zeitschriftname/jahr/monat/ *direkt* verarbeiten. Dazu
> müsste nämlich in $root/zeitschriftname/jahr/monat/ ein Skript liegen.
Ich weiß nicht genau, was ein »Dispatcher« ist. Es reicht aber, wenn in
$root/zeitschriftenname ein Skript liegt. Das verringert zwar die
Flexibilität für den Kunden, der das CMS nutzt, nachträglich URLs zu
verändern. Dies ist aber meist nicht nötig und so kann ich das CMS auch
ohne mod_rewrite nutzen (z. B. falls es der Webhoster nicht anbietet).
Viele Grüße
Gustaf
Nico Haase
*Gustaf Mossakowski* schrub:
>>> Ich habe mir deine Site angeschaut. Die URLs bei der Suche sehen noch
>>> stark nach Joomla! aus. Wieso kommt man bei »/e-commerce/« auf
>>> »/e-commerce/shops/2.html« und nicht auf »/e-commerce/shops/« (404)?
>>
>> Das ist ein Bug in der aktuellen SEF ("search engine friendly) Komponente.
>
> Also hat man doch nicht absolut freie Hand. Zumindest jetzt noch nicht.
> Das ist für Websites, die Jahre bestehen und auf ein CMS wechseln, aus
> meiner Sicht nicht zufriedenstellend. Da sollen alle alten Inhalte, wenn
> möglich und sinnvoll, weiter unter der alten URL erreichbar sein.
Das lässt sich mit anderen SEF-Modulen innerhalb von Joomla erledigen,
so kann JoomSEF nicht nur automatisch SEF-URLs erzeugen, sondern auch
eine manuell erstellte Liste durchgehen, in der bei einem Wechsel von
Joomla per Hand die alten URLs und ihre neuen Entsprechungen
gespeichert werden können.
>> Du musst die Parameter aus dem URL extrahieren. Darum kommst du nicht
>> herum. Außerdem musst du mittels mod_rewrite auf den Dispatcher
>> umleiten. *Kein* System kann den URL
>> example.com/zeitschriftname/jahr/monat/ *direkt* verarbeiten. Dazu
>> müsste nämlich in $root/zeitschriftname/jahr/monat/ ein Skript liegen.
>
> Ich weiß nicht genau, was ein »Dispatcher« ist. Es reicht aber, wenn in
> $root/zeitschriftenname ein Skript liegt. Das verringert zwar die
> Flexibilität für den Kunden, der das CMS nutzt, nachträglich URLs zu
> verändern. Dies ist aber meist nicht nötig und so kann ich das CMS auch
> ohne mod_rewrite nutzen (z. B. falls es der Webhoster nicht anbietet).
Genauso kann der Hoster aber auch die PATH_INFO-Variante, von der du
sprichst, deaktivieren, siehe
http://httpd.apache.org/docs/2.0/mod/core.html#acceptpathinfo. Und
deine Lösung braucht noch mehr Einstellungen: Liegt unter
$root/zeitschriftenname ein Script, nimmt es
$root/zeitschriftenname/abc nicht zwingend entgegen. Hierfür müsste
zeitschriftenname selbst ein Script sein und der Webserver dieses
Script - ohne Dateiendung, es soll ja auch richtig schön sein -
parsen.
mfg
Nico
--
www.buchtips.net - Rezensionen online
Gustaf Mossakowski
> Das lässt sich mit anderen SEF-Modulen innerhalb von Joomla erledigen,
> so kann JoomSEF nicht nur automatisch SEF-URLs erzeugen, sondern auch
> eine manuell erstellte Liste durchgehen, in der bei einem Wechsel von
> Joomla per Hand die alten URLs und ihre neuen Entsprechungen
> gespeichert werden können.
Zweifel ich gar nicht an. Nur scheint das System noch Bugs zu haben.
Nicht schlimm, die werden sicher behoben, aber für meine Zwecke wäre das
System daher erstmal nicht nutzbar.
> Genauso kann der Hoster aber auch die PATH_INFO-Variante, von der du
> sprichst, deaktivieren, siehe
> http://httpd.apache.org/docs/2.0/mod/core.html#acceptpathinfo.
Meine Erfahrung zeigt mir, dass es mehr Hoster gibt, die mod_rewrite
deaktivieren als PathInfo. Soweit ich weiß, ist diese Funktionalität bei
Apache 1.3 standardmäßig angeschaltet. Es ist nicht mein bevorzugtes
Mittel, aber es ist immer gut, eine Alternative zu haben.
> Und
> deine Lösung braucht noch mehr Einstellungen: Liegt unter
> $root/zeitschriftenname ein Script, nimmt es
> $root/zeitschriftenname/abc nicht zwingend entgegen. Hierfür müsste
> zeitschriftenname selbst ein Script sein
Ein Skript ist ein Skript.
> und der Webserver dieses
> Script - ohne Dateiendung, es soll ja auch richtig schön sein -
> parsen.
Genau, dafür braucht man dann MultiViews.
Viele Grüße, Gustaf
Niels Braczek
> Niels Braczek schrieb:
>> Joomla! braucht die Information, dass die Komponente "Content"
>> (com_content) die Seite 12 anzeigen (view) soll.
>
> Dann hatte ich das ja richtig verstanden. Diese Logik (welche
> Komponente, was passiert damit) würde ich direkt in der Datenbank oder
> dem CMS dem Inhalt zuweisen, nicht über die URL bestimmen.
Das lässt sich doch nur über den URL bestimmen. Anders wären Links auf
Content nicht möglich.
>> Das ist ein Bug in der aktuellen SEF ("search engine friendly) Komponente.
>
> Also hat man doch nicht absolut freie Hand. Zumindest jetzt noch nicht.
> Das ist für Websites, die Jahre bestehen und auf ein CMS wechseln, aus
> meiner Sicht nicht zufriedenstellend. Da sollen alle alten Inhalte, wenn
> möglich und sinnvoll, weiter unter der alten URL erreichbar sein.
Solche URLs kann man explizit angeben; das hatte ich nicht gemacht. Die
URLs, die du gesehen hast, waren alle automatisch ohne Eingriffe
meinerseits erzeugt.
>> Es besteht aber die
>> Möglichkeit, den selben Inhalt in verschiedenen Perspektiven anzubieten.
>> Oft hat man sogar dieselbe Perspektive zweimal, zB. "Links" oder
>> "Impressum" im Service-Menü *und* in der normalen Navigation. Dann
>> benötigt man die Itemid, um festzustellen, welcher Menüpunkt
>> hervorgehoben werden soll.
>
> Das fand ich bei Joomla! eher verwirrend. Normale Navigation könnte
> sowas am linken Rand sein und das Service-Menü dann z. B. eine Fußzeile?
> Auf der Seite /impressum/ würde ich dann »Impressum« sowohl in der
> Fußzeile als auch im Service-Menü fett und aktiviert darstellen, ohne
> Link auf sich selbst. Das scheint aber nicht standardmäßig vorgesehen zu
> sein, auf deiner Seite verlinken die Seiten sich selbst.
Bei "Impressum" mag das noch gehen; wenn es zu den jeweiligen
menüpunkten aber Unterpunkte gibt, führt das zu Problemen.
>>> Wenn ich auf »ungefähre Kosten« klicke, unter Webdesign, passiert
>>> nix. Schade ;-) Das ist doch immer mit das Interessanteste ... Da
>>> sind noch ein paar kleine Fehler drin, falls Interesse besteht,
>>> schreibe ich die gerne per Mail, gehört ja aber hier nicht in die
>>> Diskussion.
>>
>> Das muss ich mir in der Tat mal genauer ansehen. Da stimmt was nicht
>> :-(. Schick mir bitte diese Mail...
>
> Habe ich gestern verschickt.
Danke! Woher die rekursive Weiterleitung kommt, habe ich noch nicht
herausgefunden. Die anderen Punkte habe ich bereits bereinigt.
>> Der einzige Unterschied ist doch, dass die Zuordnung der Parameter über
>> ihre Position und nicht über den Namen erfolgt. Sie sind deshalb
>> verpackt, weil die Information verdichtet ist.
>
> www.bsds.de statt 212.227.245.92 ist auch nur Kosmetik, trotzdem bietet
> es Vorteile: leichter zu merken, und, ähnlich CMS-URLs, bei einem
> Serverumzug muß man sich keine neue Adresse merken.
Das ist richtig. Deshalb und wegen der zusätzlich Scores bei
Suchmaschinen setzt man technische URLs ja in sprechende URLs um.
> Ich glaube, dass das ein Kernpunkt in unserer Diskussion ist. Meine
> Aussage, dass sprechende URLs Teil des Gerüsts des WWW sind, war ja
> ursprünglich der Auslöser. Du betrachtest es eher als technisches, ich
> eher als soziales Phänomen, so mein Eindruck. Bitte korrigiere mich,
> wenn ich da falsch liege.
Das sehe ich ich auch so. Du sagtest allerdings, sprechende URLs seien
das *Grund*gerüst des WWW, was für mich technische Notwendigkeit
impliziert. Nur gegen diesen Aspekt richtete sich mein Einwand.
>> Du musst die Parameter aus dem URL extrahieren. Darum kommst du nicht
>> herum. Außerdem musst du mittels mod_rewrite auf den Dispatcher
>> umleiten. *Kein* System kann den URL
>> example.com/zeitschriftname/jahr/monat/ *direkt* verarbeiten. Dazu
>> müsste nämlich in $root/zeitschriftname/jahr/monat/ ein Skript liegen.
>
> Ich weiß nicht genau, was ein »Dispatcher« ist.
Ein Dispatcher ist ein Skript, das die Aufgaben an die zuständigen
Stellen verteilt. Bei Joomla! zB. ist das in erster Instanz die
index.php, die wiederum den Dispatcher der angeforderten Komponente
(option=) aufruft und ihm mitteilt, was (task=) womit (id=) zu tun ist.
Anzeige-Konfigurationen werden zentral vom Kern verwaltet und über den
augewählten Menüpunkt (Itemid=) gesteuert[*].
> Es reicht aber, wenn in
> $root/zeitschriftenname ein Skript liegt. Das verringert zwar die
> Flexibilität für den Kunden, der das CMS nutzt, nachträglich URLs zu
> verändern. Dies ist aber meist nicht nötig und so kann ich das CMS auch
> ohne mod_rewrite nutzen (z. B. falls es der Webhoster nicht anbietet).
Das reicht nicht ohne irgendwelche technischen Vorkehrungen, die dafür
sorgen, dass $root/zeitschriftname/jahr/monat/ nicht als Pfad
interpretiert wird (das ist das Standard-Verhalten, wenn keine Zusätze
genutzt werden). Üblicherweise wird mod_rewrite eingesetzt. Auf jeden
Fall ist eine Umsetzung des URLs in Skript und Parameter zwingend
erforderlich.
Dem Verlauf unserer Diskussion entnehme ich, dass wir uns eigentlich
einig sind. Ich fasse das mal zusammen:
Sprechende URLs sind sinnvoll und sollten auf jeden Fall so weit wie
möglich genutzt werden. Sie sind aber keinesfalls technisch notwendig.
In jedem Falle muss eine Übersetzung der sprechenden URLs auf Skript und
Parameter erfolgen.
[*] Darin liegt genau das Problem. Die Komponenten werden über den
Menüpunkt konfiguriert. Das ist eine Altlast aus Mambo-Zeiten, die man
aus 1.0.x nicht entfernen kann, um die Kompatibilität zu erhalten.