otherland: Netscape

Ich muss eine Anwendung mit einer in bestimmter Art aufbereiteten URI aufrufen. Diese URI enthält Text, welcher keinesfalls vom Browser interpretiert (encoded) werden darf.
Als Beispiel sei hier folgender Teil der URI genannt:
&W6=Dies+ist+§+8&O6=false
Erschwerent kommt hinzu, dass der Link über eine kleine JavaScript-Funktion aufgerufen wird.

IE, NS 4 und Opera 7 verhalten sich ganz artig und übermitteln genau die oben geschriebenen Zeichen. NS 7 jedoch encoded dass erste (und alle weiteren) Sonderzeichen und ab da ebenfalls alle "&"-Zeichen etc. was natürlich zu einer Fehlfunktion führt.

So sieht die Teil-URI dann unter NS 7 aus:
&W6=Dies+ist+%A7+8%26O6%3Dfalse

Ein decoden ist auf dem Empfängerserver ausgeschlossen.

Hat jemand eine Idee?

  1. Hi,

    Diese URI enthält Text, welcher keinesfalls vom Browser interpretiert (encoded) werden darf.

    der serverseitige Mechanismus ist defekt. Er *darf* nicht verlangen, dass ein Client etwas nicht kodiert, das zu kodieren ihm per RFC erlaubt ist.

    &W6=Dies+ist+§+8&O6=false

    Ich nehme an, dieses "§" ist ein Umlaut oder so, der sogar kodiert werden *muss*.

    NS 7 jedoch encoded dass erste (und alle weiteren) Sonderzeichen und ab da ebenfalls alle "&"-Zeichen etc. was natürlich zu einer Fehlfunktion führt.

    Sorge selbst für die richtige Kodierung - das ist Deine *Pflicht*. Sowie Du Dich auf die Fehlerkorrektur des Browsers verlässt (oder sogar auf dessen Fehlen!), ist es absurd anzunehmen, das Ergebnis sei abzusehen.

    Ein decoden ist auf dem Empfängerserver ausgeschlossen.

    Das Ding hat im Internet nichts verloren.

    Cheatah

    --
    X-Will-Answer-Email: No
    X-Please-Search-Archive-First: Absolutely Yes
    1. der serverseitige Mechanismus ist defekt. Er *darf* nicht verlangen, dass ein Client etwas nicht kodiert, das zu kodieren ihm per RFC erlaubt ist.

      &W6=Dies+ist+§+8&O6=false

      Ich nehme an, dieses "§" ist ein Umlaut oder so, der sogar kodiert werden *muss*.

      Sorge selbst für die richtige Kodierung - das ist Deine *Pflicht*. Sowie Du Dich auf die Fehlerkorrektur des Browsers verlässt (oder sogar auf dessen Fehlen!), ist es absurd anzunehmen, das Ergebnis sei abzusehen.

      Ein decoden ist auf dem Empfängerserver ausgeschlossen.

      Das Ding hat im Internet nichts verloren.

      Cheatah

      ____________

      Danke für Dein Kommentar, hilft aber nicht wirklich weiter.
      Der Teil der Url lautet:
      &W6=Dies+ist+§+8&O6=false

      Also ist es kein Umlaut sondern ein Paragraphenzeichen.

      MFG
      Otherland

      1. Hi,

        Danke für Dein Kommentar, hilft aber nicht wirklich weiter.

        Dein Problem ist auf Serverseite zu lösen.

        Der Teil der Url lautet:
        &W6=Dies+ist+§+8&O6=false
        Also ist es kein Umlaut sondern ein Paragraphenzeichen.

        Der Search-Part von HTTP-URLs darf laut RFC 1738 (http://www.ietf.org/rfc/rfc1738.txt) folgende Zeichen beinhalten:

        search         = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
        uchar          = unreserved | escape
        unreserved     = alpha | digit | safe | extra
        safe           = "$" | "-" | "_" | "." | "+"
        extra          = "!" | "*" | "'" | "(" | ")" | ","

        alpha sind Buchstaben, digit Ziffern, escape die "%xy"-Sequenzen. Ein Paragraphenzeichen sehe ich dort nicht. Ergo: Jeder Client, der das Zeichen *nicht* escaped bzw. die URL gleich als defekt ablehnt, verhält sich mindestens grob fahrlässig.

        Cheatah

        --
        X-Will-Answer-Email: No
        X-Please-Search-Archive-First: Absolutely Yes
        1. Hi

          Dein Problem ist auf Serverseite zu lösen.

          Da besteht leider kein Zugriff für mich.

          Der Teil der Url lautet:
          &W6=Dies+ist+§+8&O6=false
          Also ist es kein Umlaut sondern ein Paragraphenzeichen.

          Der Search-Part von HTTP-URLs darf laut RFC 1738 folgende Zeichen beinhalten:

          search         = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
          uchar          = unreserved | escape
          unreserved     = alpha | digit | safe | extra
          safe           = "$" | "-" | "_" | "." | "+"
          extra          = "!" | "*" | "'" | "(" | ")" | ","

          Nun, das Problem betrifft auch nicht nur das Paragraphenzeichen. Deutsche Umlaute (=alpha) führen zu demselben Ergebnis.

          IE, Opera 7 und NS 4 (alle unter Win32) verfahren hier auch ganz in meinem Sinne. Nur NS7 (und warscheinlich Mozilla - bisher nicht getestet) tanzen aus der Reihe.

          Viele Grüße,

          otherland

          1. Hi,

            Dein Problem ist auf Serverseite zu lösen.
            Da besteht leider kein Zugriff für mich.

            das Ding hat eliminiert zu werden. Es ist *defekt*, es richtet potentiell Schaden an. Wenn Du es nicht reparieren kannst, sorge für die Deaktivierung.

            Nun, das Problem betrifft auch nicht nur das Paragraphenzeichen. Deutsche Umlaute (=alpha) führen zu demselben Ergebnis.

            Selbstverständlich, aus dem gleichen Grund.

            IE, Opera 7 und NS 4 (alle unter Win32) verfahren hier auch ganz in meinem Sinne.

            Sie verfahren *falsch*, es ist völlig egal, ob das in Deinem Sinne ist oder nicht. FYI: Niemand kann einen Client daran hindern, stinknormale Buchstaben zu kodieren. Die Serverseite hat das zu handhaben - oder vom Netz genommen zu werden.

            Nur NS7 (und warscheinlich Mozilla - bisher nicht getestet) tanzen aus der Reihe.

            Es ist bedauerlich, dass korrektes Verhalten als "aus der Reihe tanzen" wirkt. Mozilla verhält sich als einziges der von Dir getesteten Systeme nicht auf sträfliche Weise.

            Cheatah

            --
            X-Will-Answer-Email: No
            X-Please-Search-Archive-First: Absolutely Yes
            1. Hi Cheata

              Nur NS7 (und warscheinlich Mozilla - bisher nicht getestet) tanzen aus der Reihe.

              Es ist bedauerlich, dass korrektes Verhalten als "aus der Reihe tanzen" wirkt. Mozilla verhält sich als einziges der von Dir getesteten Systeme nicht auf sträfliche Weise.

              Sorry, die Aufgabe eines Browsers sehe ich nicht darin Prinzipienreiterei zu betreiben sondern "nur" zu funktionieren. Das hat Microsoft schon lange, Opera endlich aber Netscape noch nie verstanden. Die Kunst ist es eben _nicht_ sich immer auf vermeindliche Dogmen zurückzuziehen, sondern das zu tun, was gewollt ist.
              Ich werde also NS damit endgültig aus der Liste der unterstützten Browser entfernen müssen. Naja, ein allzugroßer Verlust ist es nicht. Es kann nicht angehen, dass für 2% aller Besucher 95% Aufwand betrieben wird.

              1. Hallo Otherland

                Sorry, die Aufgabe eines Browsers sehe ich nicht darin Prinzipienreiterei zu betreiben sondern "nur" zu funktionieren.

                Die Standard wurden festgelegt, damit _jeder_, Server wie Browser, weiß, was er von seinem Gegeüber erwarten kann. Ein Server bzw. Browser, der es nicht schafft, dem Standard entsprechende Requests bzw. Responses zu verarbeiten, ist _defekt_. Wenn du ihn nicht ändern kannst, tausche ihn aus.

                Das hat Microsoft schon lange, Opera endlich aber Netscape noch nie verstanden.

                Micro$oft hat sich schon immer einen Dreck um irgendwelche Standards geschert. Das Ergebnis sieht man im Internetexplorer, der allen Schrott interpretiert, aber nicht vernünftig CSS kann.

                Die Kunst ist es eben _nicht_ sich immer auf vermeindliche Dogmen zurückzuziehen, sondern das zu tun, was gewollt ist.

                Die Kunst ist es, ein Programm so zu schreiben, dass es sich mit anderen Programmen, Benutzern, etc. verständigen kann. Dies kann man dadurch erreichen, dass man sich an allgemein anerkannte Standards hält. Wenn ein programm zusätzlich, der Kompatibilität, wegen auch nicht standardisierte Antworten erkennt, ist dies ein Zusatz. Dies darf aber _niemals_, ich wiederhole _niemals_ vorrausgesetzt werden.

                Ich werde also NS damit endgültig aus der Liste der unterstützten Browser entfernen müssen. Naja, ein allzugroßer Verlust ist es nicht. Es kann nicht angehen, dass für 2% aller Besucher 95% Aufwand betrieben wird.

                Ein allzugroßer Verlust ist es nicht. Es kann nicht angehen, dass ein Server keine ordnungsgemäßen Requests versteht.

                Gruß,

                Johannes

                --
                ss:| zu:} ls:[ fo:} de:] va:} ch:) sh:( n4:| rl:( br:< js:| ie:{ fl:( mo:}