-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Milo,
On 11/6/13, 5:22 PM, Milo Hyson wrote: > I wasn't trying to "play games," I was trying to route HTTP > requests. Again, this is something I have done, without incident, > for many years. It's possible I've just been lucky, but it's also > possible this isn't as big of a deal as you seem to think. The only way to reliably mutate context-paths during proxying is to re-write the headers and content of the pages. It's miserable. > I often employ common header content as you described earlier, and > yes, that does preclude the use of a hardcoded link such as > ../../some/other/resource. It does not, however, preclude the use > of a dynamic context-relative reference. To be clear, I've *only* been recommending context-relative resources. > In a servlet engine it is a simple matter to determine, for any > given browser request, the relative path necessary to reach the top > of the context. From there, any internal location can be appended. > Thus, in my site-wide content, I can put something like the > following (in VTL): > > <a href="$relativeContextPath/some/other/resource">…</a> Note that it's much more convenient to use Velocity Tools' LinkTool, which not only can construct "relative" URLs, but it will properly encode them with the session id when cookies are not in use. Also note that "relative" links will become context-relative links. > This will ultimately be seen by the browser as > ../../some/other/resource or ../some/other/resource or whatever is > appropriate given the particular request. Now I'm willing to > consider there may be flaw in that approach, but if there is it > hasn't bitten me yet. You have been fairly lucky. You must not use #parse() a lot. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSe7hKAAoJEBzwKT+lPKRYlvoP/1gEH6jSyfzeNoENoUaeBOKu FGEkDr8i8Tw7o+xbZhxoKut7RBPdDNM6OKPK4YSWTSGYMlPD07/04oF8579SEkoX iAJpvpLOjAkQ+rviLzCwy7z85CUsdJYI7XtIJKtP5+ItrEdZyFmCeCP13FuldHqW FvPoT5jWz4bfvumSo9odgBIBaN/TlltMY873S3IZvmbJ2qEEDslclYZ9A9pUzTDg d9Q8okpfEXaeYSPspsBlUtx3gMU3B7WsLthhqsmHSKOYfGf+7LWLSVfy9y5tH49u j/GuRiobZTzHDFOkaQp41mzhHsW3zUCqjxE+Q0+Qwrv3mmWXlNAPCpdvhZRh7HBA OobrWcm+4By67nKDBWZDv/q4Ik/RBG9I1vLMrrtnsudtuBWuOtRXag0oKx9wTt4k wpVckeL8+IVCvj8kdj+fcxkL7lq56m3IcZA/rP7a4ba405RnX8RI5YZEfHgaZ4rt 9+fgUAjrAs/3vud7J2J/Jp+EEIkxZF/jGBtwMKOkYa6kfWmK53Pg5SIfT2h1W9EY eOYjyidUbYLRoSm95VlLRY4PPwCDvcxyYOkN9q0XJ1cTAwrgxvUxUcYyNeNDQiVp JzoOcHJxzy1X/6gmKCu4x/RxaZMe2GDOQWTKjg7PUGsMDTii1XXkJ2Eyfofnw4pK XRVW+TJIN4sTTgjfVF9w =Y+ky -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
