Linkcounter
Alex
- php
Hallo
ich würd gern einen Linkcounter machen ich habe vor ihn mit MySQL zu machen so dass er automatisch ne neue zeile anlegt für jeden Link den er no ned hat usw. da ist doch MySQL besser als wenn ich es nur über eine Deite machen würde?
So jezt zu meinem Problem wie kann ich die Seite öffnen nachdem ich den Counterstand erhöht habe Muss ich das mit diesem META Tag machen oder kann man das auch irgendwie mit fopen oder so machen??
Würde mich über Antworten freuen
mfg
Alex
Moin!
Mit PHP gehts so:
header: ("Location: Deine neue Uri")
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix®
Moin!
UPS!
header("Location: Deine neue Uri");
fastix®
Hallo,
danke es hat Funktioniert ;)
Kann man das jezt auch mit einer Textdatei machen, so dass man auch Links löschen kann usw. (also in einem Admin Bereich) oder ist es mit MySQL viel einfacher??
mfg
aLex
Hallo Alex,
Kann man das jezt auch mit einer Textdatei machen, so dass man auch Links löschen kann usw. (also in einem Admin Bereich) oder ist es mit MySQL viel einfacher??
MySQL ist insofern einfacher, dass Du Dir keine Gedanken um File-Locking machen musst. Denn wenn mehrere gleichzeitig das Script aufrufen, dann kann es ohne File-Locking zu Problemen führen. Außerdem dürfte MySQL sehr viel performanter sein, sobald Du mehr als bloß ein paar Links hast.
Viele Grüße,
Christian
Hallo fastix®,
header("Location: Deine neue Uri");
Vielleicht sollte man noch dazu sagen, dass der Standard hier explizit eine _komplette_ URL vorsieht, also mit http:// usw.
Teile von URLs (also /test.html oder test.html oder so etwas) funktionieren in vielen Browsern auch, aber ein korrekter Browser darf (sollte? muss?) die Weiterleitung in so einem Fall nicht erfolgen lassen. Also immer darauf achten, dass das http:// immer mit dabei ist.
Viele Grüße,
Christian
Moin!
Vielleicht sollte man noch dazu sagen, dass der Standard hier explizit eine _komplette_ URL vorsieht, also mit http:// usw.
Nein. Es muss eine Uri sein. Ich habe das absichtlich klein geschrieben, weil so das "i" eindeutiger ist. Nicht uniform "request location", sondern "uniform request information".
Und natürlich beginnen (hier) beide mit "http://" aber zwingend ist das nicht...
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix®
Moin!
Und natürlich beginnen (hier) beide mit "http://" aber zwingend ist das nicht...
Äh halt: Die Aufführung des Protokolls ist zwingend. Es könnte aber, theorethisch, ein anderes drinstehen. Die Frage ist dann nur: Was macht der Browser mit der Information...
Ach so: Eine Url ist ein Teil der Uri, die wiederum die Teile nicht haben muss, die die Differenz zwischen einer Uri und einer Url ausmachen, um gültig zu sein. Dann ist eben Url=Uri...
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix®
Hallo fastix®,
Ach so: Eine Url ist ein Teil der Uri, die wiederum die Teile nicht haben muss, die die Differenz zwischen einer Uri und einer Url ausmachen, um gültig zu sein. Dann ist eben Url=Uri...
Hast Du Dich hier vielleicht nur mißverständlich ausgedrückt? Kennst Du http://www.w3.org/Addressing/?
Viele Grüße,
Christian
Moin!
Hast Du Dich hier vielleicht nur mißverständlich ausgedrückt? Kennst Du http://www.w3.org/Addressing/?
Da steht praktisch genau das. Eine Url ist eine Teilmenge der Uri oder genauer: Url's sind eine Teilmenge der Uri's:
<zitat>
_______________________________________________________
| ________________ |
| | ftp: | |
| | gopher: | |
| | http: __|____________ |
| | etc | | urn: | |
| |_____________|__| | |
| URLs | | |
| |_______________| |
| URNs |
|_______________________________________________________|
URIs
</zitat>
Und in der RFC 2396http://www.ietf.org/rfc/rfc2396.txt, Seite 21 steht geschrieben:
if scheme is defined then
append scheme to result
append ":" to result
if authority is defined then
append "//" to result
append authority to result
append path to result
if query is defined then
append "?" to result
append query to result
if fragment is defined then
append "#" to result
append fragment to result
Also: URI:
http://pfad zur datei?query#anker
oder http://was.weis.ich.wo/verz/datei.xyz?was=wie#wo
Das ist die URI.
URL:
http://was.weis.ich.wo/verz/datei.xyz
Obwohl in http://www.w3.org/Addressing/URL/url-spec.txt (Seite 13) ausdrücklich die search erwähnt ist glaube ich in der Literatur immer gelesen zu haben, das die search und das fragment nicht Bestandteile der Url wohl aber der Uri seien. Wenn jetzt search und fragment in der Uri optional sind (if ... defined), dann ist eine gültige Url zugleich eine Uri. Während eine Uri (zumindest mit fraqment) nicht definierte Bestandteile enthält und deswegen der Menge der Url's nicht zugeordnet werden kann. Sie wäre ungültig.
Darüber hinaus findet sich an der von dir genannten Stelle:
Uniform Resource Locator. An informal term <wichtig>(no longer used in technical specifications)</wichtig> associated with popular URI schemes: http, ftp, mailto, etc.
Url soll also nicht länger benutzt werden... Warum? Tja. Nicht so vollständig wie die Uri.
Die Schreibweise wegen der besseren Erkennbarkeit.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix®
Hallo!
Da steht praktisch genau das. Url's sind eine Teilmenge der Uri's:
Ja, darauf wollte ich hinaus. Aus Deinem Posting ging da zumindest für mich persönlich nicht hervor, deswegen auch meine Frage, ob Du Dich nicht vielleicht nur ungeschickt ausgedrückt hast.
Achja, ich habe nur einen Punkt an Deinem Posting auszusetzen:
Obwohl in http://www.w3.org/Addressing/URL/url-spec.txt (Seite 13) ausdrücklich die search erwähnt ist glaube ich in der Literatur immer gelesen zu haben, das die search und das fragment nicht Bestandteile der Url wohl aber der Uri seien.
Nicht ganz. 'search' oder 'query' ist ein Bestandteil der URL, 'fragment' jedoch nicht. Bei einer HTTP-Anfrage ist eine URL erlaubt, eine URI nicht zwangsläufig:
GET /cgi-bin/search.pl?q=hallo HTTP/1.1
Host: www.example.org
ist erlaubt,
GET /cgi-bin/search.pl?q=hallo#ergebnis1 HTTP/1.1
Host: www.example.org
jedoch nicht.
(vgl. RFC 1738, http://www.rfc-editor.org/rfc/rfc1738.txt, Abschnitt 3.3; RFC 2616, http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2, Abschnitt 3.2.2; eine in der Einleitung von RFC 2396 angekündigte genaue erneute Festlegung von HTTP-URLs in einem weiteren RFC ist mir nicht bekannt, daher sehe ich in RFC 1738 in dieser Hinsicht den gültigen Standard)
Viele Grüße,
Christian
hi,
Nicht uniform "request location", sondern "uniform request information".
und nicht information, sondern identifier ;-)
gruss,
wahsaga