ChrisB: Apache: 403 statt 404 bei falschem Encoding

Hi,

fordere ich von meinem lokalen Apachen die Ressource /nöt-found.htm an (bzw. kodiert als /n%C3%B6t-found.htm), so wird mein per ErrorDocument 404 eingestelltes Fehlerscript aufgerufen.

Wenn das Encoding jedoch nicht „stimmt”, also vom Client bspw. /n%F6t-found.htm angefordert wird - dann bekomme ich als Antwort nur ein 403 Forbidden; und das auch noch mit dem Default-403-Dokument des Apachen, nicht mit meinem per ErrorDocument 403 selbst festgelegten.

Im Error-Log findet sich dann der Eintrag
(22)Invalid argument: Cannot map GET /n%F6t-found.htm HTTP/1.1 to file

Der Apache „traut” sich also offenbar nicht, im Dateisystem Ressourcen zu mappen, die nicht zur Kodierung des Dateisystems passen, oder wie ist das zu verstehen - ein Request, der allzu „komische” Sonderzeichen enthält, könnte ja potentiell schädlich sein?

Jetzt suche ich eine Möglichkeit, ihm das abzugewöhnen. So, dass auch in solchen Fällen *mein* ErrorDocument 404 angezeigt wird.

(URL-gerechte Kodierung von Ressourcen ist hier nicht das Thema; die ist selbstverständlich an den Stellen, an denen ich es selber unter Kontrolle habe. Aber bei Verlinkungen „von aussen” ist das nun mal nicht immer der Fall, und auf diese möchte ich mit meinem Fehlerdokument und dem Status 404 reagieren können, und nicht nur mit 403 mit dem Default-Dokument des Apachen.)

MfG ChrisB

--
“Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]
  1. Hallo Chrisb,

    Wenn das Encoding jedoch nicht „stimmt”, also vom Client bspw. /n%F6t-found.htm angefordert wird - dann bekomme ich als Antwort nur ein 403 Forbidden; und das auch noch mit dem Default-403-Dokument des Apachen, nicht mit meinem per ErrorDocument 403 selbst festgelegten.

    Im Error-Log findet sich dann der Eintrag
    (22)Invalid argument: Cannot map GET /n%F6t-found.htm HTTP/1.1 to file

    der Fehler lässt sich nicht reproduzieren. Ich kann mich auch noch dunkel an einen Bug letzten Jahr erinnern, der zu einer generellen Umbenennung URL-codierter Pfadangaben in den Logs geführt hatte. Also erhalte ich in meinem Log auch Einträge wie /pfad/n\xc3\xb6t-found.htm und /pfad/n\xf6t-found.htm. Ohne weiteres würde ich erstmal zu einem Update des Webservers raten, _aber_ das nächste auffällige ist, dass "Invalid argument" bemängelt wird. Was für vom default abweichende Konfigurationen wirken auf die Anfragen?

    Jetzt suche ich eine Möglichkeit, ihm das abzugewöhnen. So, dass auch in solchen Fällen *mein* ErrorDocument 404 angezeigt wird.

    Das sollte sich mit mod_rewrite, Flag [PT] und z. B. PHP hinbiegen lassen; dazu vielleicht mehr nach der Konfigurationsangabe.

    Gruß aus Berlin!
    eddi

    1. Hi,

      Im Error-Log findet sich dann der Eintrag
      (22)Invalid argument: Cannot map GET /n%F6t-found.htm HTTP/1.1 to file

      der Fehler lässt sich nicht reproduzieren.

      Er tritt offenbar nur auf, wenn man den Apachen unter Windows betreibt.

      Ohne weiteres würde ich erstmal zu einem Update des Webservers raten,

      Ich verwende 2.2.14, was aktuell die „best available version” ist.

      _aber_ das nächste auffällige ist, dass "Invalid argument" bemängelt wird.

      S.o., scheint sich um eine Eigenart unter Windows zu handeln; ich vermute, dass damit das dahinter liegende Dateisystem vor Requests geschützt werden soll, die ggf. gefährlich sein könnten, wenn der Webserver sie tatsächlich ans Dateisystem weiterreichen würde.

      Das sollte sich mit mod_rewrite, Flag [PT] und z. B. PHP hinbiegen lassen

      Zum Rewriting kommt man damit gar nicht mehr, weil der 403 schon in der vorherigen Phase der Requestverarbeitung „fest steht”.

      Aber wie gesagt, wenn das nur unter Windows auftritt, ist es für mich weniger relevant.

      MfG ChrisB

      --
      “Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]
      1. Re:

        S.o., scheint sich um eine Eigenart unter Windows zu handeln; ich vermute, dass damit das dahinter liegende Dateisystem vor Requests geschützt werden soll, die ggf. gefährlich sein könnten, wenn der Webserver sie tatsächlich ans Dateisystem weiterreichen würde.

        Das sollte sich mit mod_rewrite, Flag [PT] und z. B. PHP hinbiegen lassen

        Zum Rewriting kommt man damit gar nicht mehr, weil der 403 schon in der vorherigen Phase der Requestverarbeitung „fest steht”.

        Aha, danke für die Info!

        Gruß aus Berlin!
        eddi

      2. Eine Sache noch aus Interesse, weil bei mir kein Indiander aus dem Fenster lukt:

        Ließe sich das Problem mit mod_speling beheben?

        Gruß aus Berlin!
        eddi

      3. Hi Chris,

        der Fehler lässt sich nicht reproduzieren.

        Er tritt offenbar nur auf, wenn man den Apachen unter Windows betreibt.

        Ja, bei mir auch: Apache/2.2.14 (Win32) PHP/5.3.0

        Ein 'ü' in die Adresszeile eingetippt wird zum %FC und der Apache haucht einen 403. Ein '%c3%bc' hingegen quittiert er mit 404.

        Interessant wirds, wennn ich die
        RewriteRule ^.*.html$
        einschalte, die bei einem %c3%bc.html greift, wo ich (mein Script) einen 410 schicke, weil %c3%bc.html nicht in der Content-DB enthalten ist. Gebe ich jedoch ein ü.html ein, wird dies zu einem %FC.html und es kommt ein Status 403, da wird mein Script gar nicht erst angezogen.

        Vielleicht helfen diese Infos beim Froschen ;-)
        Horst Jungknickel

  2. Hi,

    Wenn das Encoding jedoch nicht „stimmt”, also vom Client bspw. /n%F6t-found.htm angefordert wird - dann bekomme ich als Antwort nur ein 403 Forbidden; und das auch noch mit dem Default-403-Dokument des Apachen, nicht mit meinem per ErrorDocument 403 selbst festgelegten.

    Im Error-Log findet sich dann der Eintrag
    (22)Invalid argument: Cannot map GET /n%F6t-found.htm HTTP/1.1 to file

    Sieht so aus, also wäre es nur eine Eigenart des Apachen unter Windows (legen zumindest Diskussionen zu der Thematik im WWW nahe).
    Sollte das der Fall sein, dann wär's mir egal, dann habe ich das Problem „live” im Web nachher nicht.

    MfG ChrisB

    --
    “Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]