location.href#

[pl]

hi,

Die Idee mit xhr.open('GET', location.href + "?query=123"); den Code unabhängig vom URL zu machen kann ziemlich in die Hose gehen. Wurde nämlich die Seite über einen Anker aufgerufen, erklärt der Browser den angehängten Querystring für null und nichtig weil er als Fragment betrachtet wird.

Das ist mir im FF untergekommen, verhalten sich da alle Browser so?

MfG

[Christian Kruse]

Hallo pl,

Das ist mir im FF untergekommen, verhalten sich da alle Browser so?

Ja. Parse die URL (z.B. mit URI.js) und manipuliere den Query-String mit entsprechenden Methoden.

LG,
CK

[pl]

hi

Das ist mir im FF untergekommen, verhalten sich da alle Browser so?

Ja. Parse die URL (z.B. mit URI.js) und manipuliere den Query-String mit entsprechenden Methoden.

Einfacher ists den Platzhalter %url% einzusetzen, falls die TE per Konfiguration nicht ausgesetzt wurde 😉

Aber URI.js ist auch eine gute Idee!

[Gunnar Bittersmann]

@@pl

Die Idee mit xhr.open('GET', location.href + "?query=123"); den Code unabhängig vom URL zu machen kann ziemlich in die Hose gehen. Wurde nämlich die Seite über einen Anker aufgerufen, erklärt der Browser den angehängten Querystring für null und nichtig weil er als Fragment betrachtet wird.

Das ist mir im FF untergekommen, verhalten sich da alle Browser so?

Das will ich doch hoffen; andernfalls verhielten sie sich falsch. Alles, was nach # kommt, ist fragment identifier. [RFC3986]

In https://example.net#foo?query=123 gibt es kein query. foo?query=123 ist fragment identifier.

LLAP 🖖

[pl]

hi

Die Idee mit xhr.open('GET', location.href + "?query=123"); den Code unabhängig vom URL zu machen kann ziemlich in die Hose gehen. Wurde nämlich die Seite über einen Anker aufgerufen, erklärt der Browser den angehängten Querystring für null und nichtig weil er als Fragment betrachtet wird.

Das ist mir im FF untergekommen, verhalten sich da alle Browser so?

Das will ich doch hoffen; andernfalls verhielten sie sich falsch. Alles, was nach # kommt, ist fragment identifier. [RFC3986]

Das ist mir schon klar. Nur war es eben nicht gleich sichtbar 😉

Und was lernen wir daraus? Richtig:

Daß der Interpreter den Code manchmal nicht so versteht wie das der Autor ursprünglich beabsichtigt hatte!

MfG

[Tabellenkalk]

Hallo,

Und was lernen wir daraus? Richtig:

Daß der Interpreter den Code manchmal nicht so versteht wie das der Autor ursprünglich beabsichtigt hatte!

Oder wie der Urgroßonkel des angeheirateten Schwippschwagers meiner Ex zu sagen pflegte: "Kommunikation ist Glücksache"

Gruß
Kalk

[pl]

hi

Und was lernen wir daraus? Richtig:

Daß der Interpreter den Code manchmal nicht so versteht wie das der Autor ursprünglich beabsichtigt hatte!

Oder wie der Urgroßonkel des angeheirateten Schwippschwagers meiner Ex zu sagen pflegte: "Kommunikation ist Glücksache"

Oder anders ausgedrückt, daß die Kommentare nicht immer zum Code passen.

MfG

PS: Richtigen Klugscheißern kann sowas natürlich nicht passieren.

[Tabellenkalk]

Hallo,

PS: Richtigen Klugscheißern kann sowas natürlich nicht passieren.

Ist ihm tatsächlich nie vorgekommen!

Gruß
Kalk

[beatovich]

hallo

Die Idee mit xhr.open('GET', location.href + "?query=123"); den Code unabhängig vom URL zu machen kann ziemlich in die Hose gehen. Wurde nämlich die Seite über einen Anker aufgerufen,

oder verfügt der URL bereits über einen query string...

[pl]

hallo

Die Idee mit xhr.open('GET', location.href + "?query=123"); den Code unabhängig vom URL zu machen kann ziemlich in die Hose gehen. Wurde nämlich die Seite über einen Anker aufgerufen,

oder verfügt der URL bereits über einen query string...

Dann wird das was angehängt wird auf jeden Fall übertragen. MfG

[beatovich]

hallo

oder verfügt der URL bereits über einen query string...

Dann wird das was angehängt wird auf jeden Fall übertragen. MfG

Ja aber was wird genau übertragen?

[pl]

hallo

oder verfügt der URL bereits über einen query string...

Dann wird das was angehängt wird auf jeden Fall übertragen. MfG

Ja aber was wird genau übertragen?

Die Frage ist berechtigt, weil das nicht gleich zu sehen ist und weil man es dem Code nicht ansieht und genau deswegen ist es nicht empfehlenswert. Aber schauen wir mal was passiert, also:

wir haben xhr.open('POST', location.href + '?insert=1');

Nun wurde die Seite mit index.html?x=y aufgerufen. Ergo steht in location.href ebendas und angehängt wir auch das was der Code beabsichtigt, so erhalten wir ?x=y?insert=1 und genau das wird auch übertragen.

MfG

[Gunnar Bittersmann]

@@pl

hallo

Die Idee mit xhr.open('GET', location.href + "?query=123"); den Code unabhängig vom URL zu machen kann ziemlich in die Hose gehen. Wurde nämlich die Seite über einen Anker aufgerufen,

oder verfügt der URL bereits über einen query string...

Dann wird das was angehängt wird auf jeden Fall übertragen.

Es wird aber nicht das angehängt, was beabsichtigt ist.

https://example.net?foo=bar?query=123 ist dann wohl ein Parameter (Key foo mit dem Wert bar?query=123) und nicht wie beabsichtigt zwei (Key foo mit dem Wert bar und Key query mit dem Wert 123).

LLAP 🖖

[pl]

hi

Die Idee mit xhr.open('GET', location.href + "?query=123"); den Code unabhängig vom URL zu machen kann ziemlich in die Hose gehen. Wurde nämlich die Seite über einen Anker aufgerufen,

oder verfügt der URL bereits über einen query string...

Dann wird das was angehängt wird auf jeden Fall übertragen.

Es wird aber nicht das angehängt, was beabsichtigt ist.

Doch, wird es. Wäre ja schlimm wenn das nicht so wäre 😉

MfG

[peter]

Es wird aber nicht das angehängt, was beabsichtigt ist.

Doch, wird es. Wäre ja schlimm wenn das nicht so wäre 😉

Beides sind valide Interpretationen des Querystrings. Ich würde erwarten, dass unterschiedliche Applikationen das unterschiedlich handhaben; WhatWG definiert einen Algorithmus, der so funktioniert wie Gunnar es erwartet (in der URL-Spec, an die sich Javascript hält), aber das Auftrennen des Strings in Parameter ist für URI lt. RFC erstmal nicht definiert und ich würde erwarten dass diverse Implemetationen (vorallem ältere) pl's Interpretation nutzen.

[pl]

Es wird aber nicht das angehängt, was beabsichtigt ist.

Doch, wird es. Wäre ja schlimm wenn das nicht so wäre 😉

Beides sind valide Interpretationen des Querystrings. Ich würde erwarten, dass unterschiedliche Applikationen das unterschiedlich handhaben; WhatWG definiert einen Algorithmus, der so funktioniert wie Gunnar es erwartet (in der URL-Spec, an die sich Javascript hält), aber das Auftrennen des Strings in Parameter ist für URI lt. RFC erstmal nicht definiert und ich würde erwarten dass diverse Implemetationen (vorallem ältere) pl's Interpretation nutzen.

Und das wo Du meine Interpretation gar nicht kennst! Beschreibe Du doch mal was Dein Parser aus einem QueryString ?x=y?a=b macht. MfG

[peter]

Beschreibe Du doch mal was Dein Parser aus einem QueryString ?x=y?a=b macht.

Was soll „mein Parser“ in diesem Zusammenhang bedeuten? Ich nutze logischerweise den von der jeweils verwendeten Umgebung vorgegebenen und für die Zielsetzung sinnvollsten Parser (und dass diese unterschiedliche Interpretationen haben können, stand ja bereits in meinem vorherigen Posting); alles andere wäre vollkommen unsinnig.

[pl]

Daß Parser RFCs unterschiedlich implementieren haben wir ja nun gerade hier schon oft genug festgestellt.

Also: Was erwartest Du bei einem QueryString x=y?a=b was der Parser liefert?

Und: Wie geht Deine Fehlerbehandlung mit unbekannten bzw. nicht erwarteten Parametern um?

MfG

[peter]

Daß Parser RFCs unterschiedlich implementieren haben wir ja nun gerade hier schon oft genug festgestellt.

Wie ich schon sagte, tun sie das hier definitiv nicht, die RFC macht dazu keine spezifische Aussage: “Parameter types may be defined by scheme-specific semantics, but in most cases the syntax of a parameter is specific to the implementation of the URI's dereferencing algorithm.”

Also: Was erwartest Du bei einem QueryString x=y?a=b was der Parser liefert?

Das was für den spezifischen Parser definiert ist. Wenn ich es implementieren würde (was ich nicht tun würde), würde ich den String hart an Ampersand und/oder Semikolon in einzelne Parameter trennen.

Und: Wie geht Deine Fehlerbehandlung mit unbekannten bzw. nicht erwarteten Parametern um?

Gar nicht, wie sollten automatisch ignorierte Dinge mit der Fehlerbehandlung in Kontakt kommen?

[beatovich]

hallo

Und: Wie geht Deine Fehlerbehandlung mit unbekannten bzw. nicht erwarteten Parametern um?

Gar nicht, wie sollten automatisch ignorierte Dinge mit der Fehlerbehandlung in Kontakt kommen?

Der parameter x wurde ursprünglich vom Script selbst gesetzt (da x=y der originale Querystring war. Es ist deshalb davon auszugehen, dass x als Parameter hier verarbeitet wird. Verändert wurde der zugewisene Parameter-Wert.

[peter]

Und: Wie geht Deine Fehlerbehandlung mit unbekannten bzw. nicht erwarteten Parametern um?

Gar nicht, wie sollten automatisch ignorierte Dinge mit der Fehlerbehandlung in Kontakt kommen?

Der parameter x wurde ursprünglich vom Script selbst gesetzt (da x=y der originale Querystring war. Es ist deshalb davon auszugehen, dass x als Parameter hier verarbeitet wird.

Ja, aber das hat mit pl's Frage (bzw. meiner Interpretation derselben) nichts zu tun, sonst hätte er ja gefragt, was ich mit unerwarteten Parameter-Werten tue? Und auch diese Frage hielte ich nicht für wesentlich sinnvoller; entweder es ist nicht erkennbar oder es führt zu definierter automatischer Fehlerkorrektur bzw. einem (hoffentlich) sinnvoll behandelten Fehler; schlimmstenfalls gilt „garbage in, garbage out“.

Verändert wurde der zugewisene Parameter-Wert.

Je nach Interpretation…

[pl]

Gar nicht, wie sollten automatisch ignorierte Dinge mit der Fehlerbehandlung in Kontakt kommen?

Nun, es ist so, daß das was der Parser liefert mit der Fehlerbehandlung eine Einheit bilden sollte, zumindest handhabe ich das so. Dann ist es auch eine Frage inwieweit Schlüsselparameter von Nutzdaten getrennt sind. Einer Parameterkontrollstruktur ist es egal welchen Wert ein Schlüsselparameter liefert solange der Boolsche Kontext stimmt. Alles was bei mir aus dieser Kontrollstruktur rausfällt führt dazu daß die Seite mit einem Status != 200 ausgeliefert wird zusammen mit einer entspechenden Fehlermeldung. Das ist dann auch maschinell verwertbar.

Und wenn ein unbekannter Parameter dazu führt, daß die Seite in text/plain ausgeliefert wird gibt es ein location.href gleich gar nicht.

MfG

PS: Mein Parser kennt übrigens mehr als nur application/x-www-form-urlencoded und multipart/form-data

[peter]

Gar nicht, wie sollten automatisch ignorierte Dinge mit der Fehlerbehandlung in Kontakt kommen?

Nun, es ist so, daß das was der Parser liefert mit der Fehlerbehandlung eine Einheit bilden sollte, zumindest handhabe ich das so. Dann ist es auch eine Frage inwieweit Schlüsselparameter von Nutzdaten getrennt sind. Einer Parameterkontrollstruktur ist es egal welchen Wert ein Schlüsselparameter liefert solange der Boolsche Kontext stimmt. Alles was bei mir aus dieser Kontrollstruktur rausfällt führt dazu daß die Seite mit einem Status != 200 ausgeliefert wird zusammen mit einer entspechenden Fehlermeldung. Das ist dann auch maschinell verwertbar.

Und wenn ein unbekannter Parameter dazu führt, daß die Seite in text/plain ausgeliefert wird gibt es ein location.href gleich gar nicht.

Ohne auf das Geschwurbel einzugehen, was hat das mit der gestellten Frage zu tun?

PS: Mein Parser kennt übrigens mehr als nur application/x-www-form-urlencoded und multipart/form-data

Dein Parser ist irrelevant für jeden außer dich.

[pl]

Ohne auf das Geschwurbel einzugehen, was hat das mit der gestellten Frage zu tun?

Da habe ich Dich ja doch richtig eingeschätzt: Daß Du gar keine Sach~ und Fachdisskusion führen wolltest die es hier im Forum ohnehin schon lange nicht mehr gibt. Schade um die Zeit die ich mir genommen habe, Dir sach~ und fachgerecht sowie ausführlich zu antworten.

Unverschämtheit!

[dedlfix]

Tach!

Ohne auf das Geschwurbel einzugehen, was hat das mit der gestellten Frage zu tun?

Da habe ich Dich ja doch richtig eingeschätzt: Daß Du gar keine Sach~ und Fachdisskusion führen wolltest die es hier im Forum ohnehin schon lange nicht mehr gibt.

So unterschiedlich wirkt etwas auf andere ... Mir kommt es eher so vor, dass das Problem beim Führen von Sach- und Fachdiskussionen oftmals auf deiner Seite liegt. Nicht nur, dass du sehr oft Begriffe in von der allgemeinen Verwendung abweichender Bedeutung verwendest, was eine Kommunikation sehr schwierig und missverständlich macht, du gehst oftmals auch nicht auf konkrete Diskussionspunkte und Nachfragen ein, sondern erzählst dann gern irgendwas anderes, vorwiegend mit Bezug zu den Artikeln deiner Website, die aber häufig vom ersten Punkt betroffen sind und auch nichts Erhellendes in die Diskussion einbringen. Es ist deshalb nicht verwunderlich, wenn jemand das als Geschwurbel und nicht zur Frage passend interpretiert.

dedlfix.

[pl]

Tach!

Ohne auf das Geschwurbel einzugehen, was hat das mit der gestellten Frage zu tun?

Da habe ich Dich ja doch richtig eingeschätzt: Daß Du gar keine Sach~ und Fachdisskusion führen wolltest die es hier im Forum ohnehin schon lange nicht mehr gibt.

So unterschiedlich wirkt etwas auf andere ... Mir kommt es eher so vor, dass das Problem beim Führen von Sach- und Fachdiskussionen oftmals auf deiner Seite liegt.

Sach~ und Fachdiskussionen sehen anders aus. Aber gerade hier ist es ja so, daß wenn auch immer ich was schreibe, sofort irgendwelche Leute sich da draufstürzen wie ein Hund auf einen Knochen und mit allen Mitteln versuchen mich als unglaubwürdig hinzustellen.

Ich habe nicht vor deinen Artikel zu lesen.

Damit machst Du Dich selbst unglaubwürdig. Leute die Bücher kritisieren ohne sie gelesen zu haben sind auch dieselben die sich hinter Fachbegriffen verstecken um ihre eigene Unsicherheit zu verbergen.

Schönen Tach auch 😉

[dedlfix]

Tach!

Sach~ und Fachdiskussionen sehen anders aus. Aber gerade hier ist es ja so, daß wenn auch immer ich was schreibe, sofort irgendwelche Leute sich da draufstürzen wie ein Hund auf einen Knochen und mit allen Mitteln versuchen mich als unglaubwürdig hinzustellen.

Das magst du so sehen, wenn ich antworte ist meine Absicht eine andere. Ich versuche dich zu verstehen, was mir aber oft nicht gelingt. Dann versuche ich meine Sichtweise der Dinge hinzuzufügen, auf die du aber meist nicht in der Weise eingehst, wie es viele andere tun. Leider ist diese Weise nicht sonderlich geeignet, einen zielführenden Dialog in Gang zu setzen. Dabei hilft auch nicht, dass konkrete Punkte oder Fragen nicht selten unbeantwortet bleiben oder aber mit Themenwechseln sowie Verweisen auf deine Seite, aus der sich mir aber auch keine Erklärung erschließt.

Ich habe nicht vor deinen Artikel zu lesen.

Damit machst Du Dich selbst unglaubwürdig. Leute die Bücher kritisieren ohne sie gelesen zu haben sind auch dieselben die sich hinter Fachbegriffen verstecken um ihre eigene Unsicherheit zu verbergen.

Das versuche ich nicht. Ich kann dir gern wiederholt sagen, was mich verunsichert. Das sind Texte, deren Inhalt sich mir nicht erschließt, weil sie zwar eine auf den ersten Blick vertraut klingende Sprache verwenden, aber dann viele Wörter enthalten, die nicht zur Botschaft passen. Außerdem sind sie meist didaktisch schlecht aufgebaut. Sie beginnen oft mit der Lösung für ein Problem, das aber nicht weiter thematisiert wird und führen mich als Leser auch nicht in nachvollziehbarer Weise durch das Thema. Ich verstehe aber viele Texte anderenorts, die sich um ähnliche Themen drehen, weil da die Fachbegriffe deutlich häufiger in üblicher Weise verwendet werden und somit für mich logisch schlüssig werden.

Ich habe es deshalb aufgegeben, deine Seiten verstehen zu wollen. Und was du auf deiner Seite machst, ist mir egal. Aber wenn du Informationen hier veröffentlichst, setze ich meine Informationen darunter, wenn mir danach ist. Damit wirst musst du leben müssen.

dedlfix.

[pl]

hi @Gunnar Bittersmann

https://example.net?foo=bar?query=123 ist dann wohl ein Parameter (Key foo mit dem Wert bar?query=123) und nicht wie beabsichtigt zwei (Key foo mit dem Wert bar und Key query mit dem Wert 123).

Korrekt! Was man auch jederzeit nachprüfen kann. Nun, unter den modernen Frameworks gibt es sehr viele die mit Mustererkennung arbeiten, Magento, Mojo, Dancer, .Net usw.

D.h., daß ein match dazu führt, daß die zum URL gehörige Klasse erkannt und eine bestimmte Aktion ausgelöst wird. Diese Mustererkennung führt aber auch dazu, daß QueryStrings matchen die so vom Programmierer gar nicht vorgesehen waren.

Dazu ist Folgendes zu sagen: Solange sich daraus kein Sicherheitsproblem ergibt ist das in Ordnung. Im Booleschen Kontext ist es egal ob ein Schlüsselparameter einmal oder mehrfach vorkommt solange die sich daraus ergebende Bedingung erfüllt ist.

In Fakt jedoch liegen gerade Sicherheitslücken darin begründet, daß man mit Mustererkennungen eben nicht alle Fälle abdecken kann, also auch die Bösartigen.

Vielleicht hat es sich ja auch schon herumgesprochen daß man mit URL Parametern keine gleichnamigen Funktionen aufrufen sollte 😉

MfG