nicht angemeldet
BB-Code ([link: ...]) klappt nicht immer
Hi,
mir ist aufgefallen, dass der BB-Code für das Link-Element nicht immer klappt! Ich weiß noch nicht genau, wann er nicht richtig klappt, aber ich glaube, immer dann, wenn man kein http:// davor setzt oder wenn die URL Parameter (also durch ?) besitzt. Bin mir da aber nicht so sicher.
Vielleicht liegt es auch an was anderem.
Mal ausprobieren:
< ohnehttp.de>
< www.ohnehttp.de>
http://www.blablabla.de/index.php?var1=wert1&var2=wert2
Könnte man das Problem, (falls es tatsächlich existiert und eins ist) evtl. beheben?
Gruß
Christian
-
hm....
das mit den Variablen scheint manchmal auch zu klappen.
Hier allerdings nicht:
< http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/methods/createpopup.asp>
Liegt evtl an den / in der Variablen.
Ich bitte um die Behebung der Probleme!!
MfG
Christian-
Hi,
das mit den Variablen scheint manchmal auch zu klappen.
es existieren keine Variablen in URLs.
Liegt evtl an den / in der Variablen.
In den Parametern.
Ich bitte um die Behebung der Probleme!!
Aber sicher doch. "/" schreibt sich im Searchpart "%27". Bleibe einfach konform zu RFC 1738 (http://www.ietf.org/rfc/rfc1738.txt), der technischen Definition des korrekten Aufbaus von URLs.
Cheatah
--
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Hallo Cheatah,
Aber sicher doch. "/" schreibt sich im Searchpart "%27". Bleibe einfach konform zu RFC 1738 (http://www.ietf.org/rfc/rfc1738.txt), der technischen Definition des korrekten Aufbaus von URLs.
Ja, aber wir hatten die Diskussion irgendwann einmal schon. Die Interpretation von RFC 1738 ist so nicht ganz richtig. Dort steht:
Within the <path> and <searchpart> components, "/", ";", "?" are
reserved. The "/" character may be used within HTTP to designate a
hierarchical structure.In dem Fall der Microsoft-URL wird ja eine hierarchische Struktur beschrieben. Daher wäre es eigentlich durchaus legitim, / nach ? zuzulassen.
Viele Grüße,
Christian-
Hi,
Ja, aber wir hatten die Diskussion irgendwann einmal schon.
ja. Ich lege hierbei größere Bedeutung auf die technischen Definitionen, als auf irgendeine natürlichsprachige Formulierung. RFC 1738 sagt:
httpurl = "http://" hostport [ "/" hpath [ "?" search ]]
search = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
uchar = unreserved | escape
unreserved = alpha | digit | safe | extra
alpha = lowalpha | hialpha (die beiden spare ich mir)
digit = (Ziffern)
safe = "$" | "-" | "_" | "." | "+"
extra = "!" | "*" | "'" | "(" | ")" | ","
escape = "%" hex hexIch sehe dort nirgendwo ein "/".
In dem Fall der Microsoft-URL wird ja eine hierarchische Struktur beschrieben. Daher wäre es eigentlich durchaus legitim, / nach ? zuzulassen.
Im Rahmen von Toleranz oder von mir aus auch Kulanz ;-) stimme ich Dir zu. Ich würde aber im Traum nicht auf die Idee kommen, einen Mechanismus, der den Slash im Searchpart ablehnt, in irgendeiner Form als falsch zu betrachten.
Cheatah
--
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Hallo Cheatah,
RFC 1738 sagt:
search = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
uchar = unreserved | escapeAllerdings sagt RFC 2396:
Network Working Group T. Berners-Lee
Request for Comments: 2396 MIT/LCS
Updates: 1808, 1738 R. Fielding
Category: Standards Track U.C. Irvine
L. Masinter
Xerox Corporation
August 1998[...]
query = *uric
uric = reserved | unreserved | escaped
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
"$" | ","Gut, man könnte argumentieren, dass weiter oben steht, dass dies nicht notwendigerweise vom einem spezifischen URL-Schema eingehalten werden muss. Allerdings wird HTTP im RFC mehrmals als Beispiel genannt.
Ich würde aber im Traum nicht auf die Idee kommen, einen Mechanismus, der den Slash im Searchpart ablehnt, in irgendeiner Form als falsch zu betrachten.
Nicht falsch, aber so ein Mechanismus wäre veraltet. Und das seit 5 Jahren. ;-)
Viele Grüße,
Christian-
RFC 1738 sagt:
[zu HTTP-Urls eine Menge]
Allerdings sagt RFC 2396:
explizit nichts zu HTTP-URLs. Lies mal die Einleitung.
H.
-
Hi,
RFC 1738 sagt:
Allerdings sagt RFC 2396:... dass die Details für das jeweilige Schema "anderswo" beschrieben werden. Da für HTTP kein spezieller RFC existiert, der noch immer aktuelle RFC 1738 dieses Schema jedoch explizit behandelt, gilt, soweit ich es beurteilen kann[1], für HTTP-URLs weiterhin RFC 1738. Oder, um es ganz deutlich zu sagen: Für HTTP-URLs gilt _nicht_ RFC 2396.
Gut, man könnte argumentieren, dass weiter oben steht, dass dies nicht notwendigerweise vom einem spezifischen URL-Schema eingehalten werden muss.
Eben :-)
Allerdings wird HTTP im RFC mehrmals als Beispiel genannt.
Ist eine HTTP-URL dabei, die von der (strengen) Definition aus RFC 1738 abweicht?
Ich würde aber im Traum nicht auf die Idee kommen, einen Mechanismus, der den Slash im Searchpart ablehnt, in irgendeiner Form als falsch zu betrachten.
Nicht falsch, aber so ein Mechanismus wäre veraltet. Und das seit 5 Jahren. ;-)Nicht wirklich, wirklich nicht ;-) Wohlgemerkt: Nicht mehr Stand der Realität. Ohne es geprüft zu haben glaube ich mich zu erinnern, dass auch nach RFC 2396 eine Tilde im Localpart der URL nicht erlaubt ist (oder?). Dies ist jedoch - leider - gängige Praxis; Tilden werden oft in Userverzeichnissen eingesetzt und (trotzdem) nicht kodiert.
Cheatah
[1] Gerne auch anders formuliert: Soweit es mich betrifft.
--
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Moin,
... dass die Details für das jeweilige Schema "anderswo" beschrieben werden. Da für HTTP kein spezieller RFC existiert
Ich kann mich immer mehr der Meinung anschließen, dass RFC 2616 Abschnitt 3.2 das versprochene Update von 1738 ist, bloß dass es nicht als solches beworben wird.
--
Henryk Plötz
Grüße aus Berlin
~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~-
Hi,
Ich kann mich immer mehr der Meinung anschließen, dass RFC 2616 Abschnitt 3.2 das versprochene Update von 1738 ist, bloß dass es nicht als solches beworben wird.
hm, ich habe diesen Absatz immer als "ach übrigens, dann gibt's da noch" angesehen. Mir ist der Bereich zu undefinitiv, zu schwankend im Thema - eigentlich mehr ein "wie sollen Systeme mit einer HTTP-URL umgehen" als ein "wie sieht eine HTTP-URL aus". Insbesondere beschreibt RFC 2616 _nicht_, wie der Searchpart aussieht (nur dass er da ist), und bezieht sich nicht einmal auf die entsprechenden Angaben in RFC 2396. Ein bisschen zu wischi-waschi für ein RFC 1738 Replace ...
Cheatah
--
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes
-
-
-
-
-
Hi Christian Seiler,
Within the <path> and <searchpart> components, "/", ";", "?" are
reserved. The "/" character may be used within HTTP to designate a
hierarchical structure.
In dem Fall der Microsoft-URL wird ja eine hierarchische Struktur beschrieben. Daher wäre es eigentlich durchaus legitim, / nach ? zuzulassen.die Frage scheint wohl zu sein, ob der <searchpart> sich (im Sinne der vorliegenden Definition) überhaupt als 'legaler' Kandidat anbietet, um _darin_ eine Hierarchie auszudrücken.
(Für den <path> ist dies ja offenbar unstrittig der Fall.)Innerhalb des <searchpart> sind beliebig viele Parameter mit beliebigen Namen in einer beliebigen Anordnung zulässig. Unter "Hierarchie" verstehe ich etwas, das für den HTTP-Server im _allgemeinen_ Sinne eindeutig interpretierbar ist - also ohne Kenntnisse darüber, wie eine konkrete serverseitige Anwendung diese Parameter (im Sinne welcher Hierarchie auch immer) interpretiert.
Für den <path> gilt diese Aussage - für den <searchpath> (in dem sinne, wie M$ ihn auf seiner site verwendet) IMHO nicht. Denn letzteres verstehe ich nicht mehr als "within HTTP" - das ist dann schon "within the evaluation logic of the server application".Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
(sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
=> http://www.peter.in-berlin.de/projekte/selfcode/?code=sh%3A|+fo%3A}+ch%3A]+rl%3A(+br%3A^+n4%3A(+ie%3A%25+mo%3A)+va%3A|+de%3A%2F+zu%3A|+fl%3A(+ss%3A)+ls%3A~+js%3A|
Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.-
Hi,
Innerhalb des <searchpart> sind beliebig viele Parameter mit beliebigen Namen in einer beliebigen Anordnung zulässig.
und mit beliebiger Semantik. HTTP an sich definiert nicht, ob z.B. ein "=" Name und Wert trennt - dies obliegt dem Gutdünken des empfangenden Systems.
Für den <path> gilt diese Aussage - für den <searchpath> (in dem sinne, wie M$ ihn auf seiner site verwendet) IMHO nicht.
Der zitierte Absatz aus RFC 2396 lässt diese Schlussfolgerung mindestens insofern zu, als er unsauber formuliert sein könnte. Ich persönlich weiß nicht, ob sich der zweite Satz auf den ersten bezieht, oder ob er eher separat zu sehen ist (und an etwas noch früheres anknüpft).
Cheatah
--
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Hi Cheatah,
Innerhalb des <searchpart> sind beliebig viele Parameter mit beliebigen Namen in einer beliebigen Anordnung zulässig.
und mit beliebiger Semantik. HTTP an sich definiert nicht, ob z.B. ein "=" Name und Wert trennt - dies obliegt dem Gutdünken des empfangenden Systems.aber gerade dann kann HTTP doch wohl auch nicht definieren, daß der "/" zur Bildung von Hierarchien reserviert sein soll - wenn nicht mal feststeht, wie viele Arten von Hierarchien innerhalb des <searchpart> existieren könnten? Innerhalb des <path> existiert nur eine Art von Hierarchie ...
Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
(sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
=> http://www.peter.in-berlin.de/projekte/selfcode/?code=sh%3A|+fo%3A}+ch%3A]+rl%3A(+br%3A^+n4%3A(+ie%3A%25+mo%3A)+va%3A|+de%3A%2F+zu%3A|+fl%3A(+ss%3A)+ls%3A~+js%3A|
Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.-
Hi,
HTTP an sich definiert nicht, ob z.B. ein "=" Name und Wert trennt - dies obliegt dem Gutdünken des empfangenden Systems.
aber gerade dann kann HTTP doch wohl auch nicht definieren, daß der "/" zur Bildung von Hierarchien reserviert sein soll
ob bestimmte Zeichen reserviert sind, ist ja auch nicht in HTTP definiert ;-)
- wenn nicht mal feststeht, wie viele Arten von Hierarchien innerhalb des <searchpart> existieren könnten?
Der Localpart von URLs wurde als hierarchisch definiert. Die Interpretation der Hierarchie-Ebenen ist noch immer schemaspezifisch (man betrachte nur das news:-Schema), aber "es hat sich halt um eine Hierarchie zu handeln". Der Searchpart jedoch unterliegt _nur_ einer Syntax, keiner Grammatik oder gar Semantik. Niemand darf mich daran hindern, mittels
?bla:foo&bar=hurz:purz=a:b&c&d
das selbe auszudrücken, was durch ein HTML-Formular als
?bla=foo&bla=bar&hurz=purz&a=b&a=c&a=d
ausgedrückt worden wäre. _Ich_ interpretiere den Searchpart. Kein RFC. Entsprechend ist dort der Begriff "Hierarchie" fehl am Platz, weil dies zumindest eine Einschränkung der Interpretationsmöglichkeiten darstellte.
Innerhalb des <path> existiert nur eine Art von Hierarchie ...
Ja :-)
Cheatah
--
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes
-
-
-
-
-
-
-
Hi,
Ich weiß noch nicht genau, wann er nicht richtig klappt, aber ich glaube, immer dann, wenn man kein http:// davor setzt oder wenn die URL Parameter (also durch ?) besitzt. Bin mir da aber nicht so sicher.
ich tippe mehr: Bei relativen URIs wird in irgendeiner Form geprüft, ob die URI auch einen Sinn macht.
< ohnehttp.de>
http://forum.de.selfhtml.org/my/ohnehttp.de dürfte, auch ohne "/my", nicht existieren.
< www.ohnehttp.de>
http://forum.de.selfhtml.org/my/www.ohnehttp.de ebensowenig.
Könnte man das Problem, (falls es tatsächlich existiert und eins ist) evtl. beheben?
Kein Problem. Wenn Du eine URL statt einer relativen URI meinst, dann schreib auch eine. Kein Protokoll, keine URL.
Cheatah
--
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes -
Hi Christian,
mir ist aufgefallen, dass der BB-Code für das Link-Element nicht immer klappt!
hier ist kein BB, sondern ein F.
Ich weiß noch nicht genau, wann er nicht richtig klappt, aber ich glaube, immer dann, wenn man kein http:// davor setzt
Warum sollte eine unvollständige Adresse funktionieren?
Zitat </faq/#Q-19>:
| Die URLs werden auf formale Gültigkeit nach den entsprechenden RFCs überprüft.
oder wenn die URL Parameter (also durch ?) besitzt.
Gab es dafür nicht ein Tool? Ich finde es leider nicht mehr.
Könnte man das Problem, (falls es tatsächlich existiert und eins ist) evtl. beheben?
Alles funktioniert so, wie gewollt.
Grüße,
Roland--
http://www.fu2k.org/alex/css/layouts/3Col_OrderedAbsolute.mhtml
http://aktuell.de.selfhtml.org/tippstricks/beitrag.htm
ss:| zu:} ls:} fo:} de:> va:} ch:| sh:) n4:& rl:| br:< js:{ ie:{ fl:{ mo:|