9 komentáře “Skryté pastičky v Tomcatu aneb zpětná kompatibilita se všude nenosí

  1. Vzdycky me prekvapi, jak je kod ve Spring Frameworku robustni. Oni uz na to proste mysleli.
    Na SpringSource je spolehnuti. Proc by nekdo pouzival neco jineho?

    Ariel

    • Jo, mluvíš mi z duše. Ze čtení Springového kódu jsem se naučil plno věcí. Nejčastější proti argument slýchám, že Spring je moc „heavy“, což je sice pravda, ale ty poklady v něm za sto stojí.

  2. Ahoj

    Vyborny clanek, uplne souhlasim.
    Jen bych upozornila na to, ze Path parameter je soucasti Path segmentu, cili jednoho „adresare“ v URI. To znamena, ze zdaleka nemusi byt na konci Stringu getPathInfo(). Proto tvuj kod na odstraneni Path parametru je spatne napsany. Pozor, prosim, na to.
    Jinymi slovy, toto je platna adresa:
    http://www.ariel-is-sexy.com/photos;showHidden=true/photosFromBath;includeNudePhotos=true/index.html

    Mejte se
    Ariel

    • Díky – tohle je asi nejvíc sexy komentář, co na blogu mám 😀

      Je v tom pěknej bordel – já jsem zase našel toto: http://www.w3.org/Addressing/rfc1808.txt
      Kde se říká, cituji:

      „Section 5 of RFC 1738 specifies that the question-mark character („?“) is allowed in an ftp or file path segment. However, this is not true in practice and is believed to be an error in the RFC. Similarly, RFC 1738 allows the reserved character semicolon („;“) within an http path segment, but does not define its semantics; the correct semantics are as defined by this document for .“

      A dále potom:

      „2.4.5. Parsing the Parameters

      If the parse string contains a semicolon „;“ character, then the
      substring after the first (left-most) semicolon „;“ and up to the end
      of the parse string is the parameters (<params>). If the semicolon
      is the last character, or no semicolon is present, then is
      empty. The matched substring, including the semicolon character, is
      removed from the parse string before continuing.“

      Což by zase dávalo zapravdu tomu mému prvnímu řešení. Každopádně pro path matching je umístění path parametrů doprostřed pathInfo naprosto nepoužitelná záležitost. Tj. ta jednodušší varianta je více méně stejně dostatečně použitelná IMHO.

      Každopádně jsem kód v zájmu formální správnosti převzal ze Spring frameworku, kde to mají předpokládám správně tak, jak jsi mě upozorňovala.

  3. Patche se vzdy backportuji, chyby tedy mizi, ale verze zustavaji stejne. Zpetne se takto udrzuje momentalne cca 20 verzi tomcatu, pokud se budeme bavit o rhelu 4, 5 a 6. Zakaznik ma ale na vyber, verze nemusi mit zmrazene. Viz y stream vs z stream. Presne tohle je to, proc se za linux plati. Stabilita a zpetna kompatibilita.

  4. Tak určitě je to past. Každopádně jsessionid v url, a to i pokud je to pouze na první request, je možná bezpečnostní díra, proto se doporučuje urlRewriting vypnout.

  5. Počkej, tím chceš říct, že na těchto distribucích se neinstalují bezpečnostní patche? Myslím, že je dobrým zvykem patchovat web / app server i z důvodu bezpečnostních záplat.

    Tj. dřív nebo později na to narazí taky. Leda, že by se postarali o nějaký dočasný fix pomocí wrappingu request objektu. Hmm, to se mi ale nějak nezdá …

  6. A prave z techto duvodu je vhodne pouzivat distribuce s dlouhou podporou napriklad rhel (tomcat je soucasti) nebo jboss eap. Tam k tomuto nedochazi. 😉