Richard, I think the rule goes that you should avoid touching server.xml for something that web.xml can do.
On Sun, Jul 21, 2019 at 4:40 AM Richard Huntrods <huntr...@athabascau.ca> wrote: > > I apologise for top posting in advance, but just a quick update and > quicker question... > > After Konstantin found my typo, I tried editing the global web.xml file > (/conf/web.xml) . In my case, this is actually the file I want based on > the behaviour described by Konstantin as this entire tomcat instance is > for this one application and it's static web pages, so *everything* > needs to have the redirect. > > After fixing the typo, I tried it again and it works perfectly. > > So now I have two ways to accomplish what I want: > 1. Edit /conf/web.xml and add the lines. > > 2. Edit server.xml and add the RewriteValve line, then create > rewrite.config in /conf/Catalina/localhost. > > So my question - which is considered "more elegant" or better, more > appropriate appoach - the valve or the change to web.xml? > > I'm leaning towards the valve simply because I kind of like the whole > concept of valves, but if editing web.xml is just as good... ? > > Thanks, > > -Richard > > > On 7/20/2019 2:08 PM, Richard Huntrods wrote: > > Sorry for top-posting. It's the default with my mail program > > (thunderbird)... > > > > On 7/20/2019 11:27 AM, Konstantin Kolinko wrote: > >> сб, 20 июл. 2019 г. в 17:47, Richard Huntrods <huntr...@athabascau.ca>: > >>> OK. That was really weird. > >>> > >>> As I said in my message, following the directions on the web did NOT > >>> work. It didn't force redirection from http to https. > >>> > >>> What it DID end up doing was to kill the tomcat servlet application. > >>> Before the change it was working fine, and after the change it would > >>> only generate a 404 page. > >>> > >>> I reverted to the original /conf/web.xml, restarted tomcat and the > >>> servlet application is back up and running perfectly. > >>> > >>> So this code in /conf/web.xml affected the servlet but not the ROOT > >>> static web pages. > >> 1. The web.xml file and its behavior are defined in the Servlet > >> Specification. > >> > >> Some random instructions on the net have to be used carefully. > >> > >> 2. The web.xml file is the one in your web application > >> (WEB-INF/web.xml). > >> > >> The /conf/web.xml file provides defaults for all web applications, and > >> SHOULD not be edited. (The /conf/context.xml should not be exited as > >> well. That is another frequent error.). > >> > >> Those defaults are merged with the web.xml file of your web > >> application using merging rules defined in the Servlet Specification. > >> > >> There is an option, "logEffectiveWebXml" [1] that turns on logging of > >> the merged web.xml file. > > I still am having trouble understanding why the web application's > > WEB-INF/web.xml would be the appropriate place to put the change when > > I want to affect ROOT. I would have thought > > webapps/ROOT/WEB-INF/web.xml would have been the correct one. > >> > >> 3. Beware of typos. > >> > >> The tag "</web-recource-collection>" is misspelled. > > > > AARRRGGGGHHHH!!!! > > > > TYPOS!!!! > > > > And I checked that code several times before implementing it. Of > > course it wouldn't work 'as designed'. Ouch. > > > > I can clearly see why 'fixing stuff' using that code would generate > > the 404 errors I was seeing. That does prove I was editing the correct > > web.xml files, at least. Since the typo was in the block that then > > defined the url-pattern, messing that up would mess up everything. > > > > One person asked what the logs said. Nothing. Start up log was normal, > > access log was normal. > > > >> > >> There is an option, "xmlValidation" [1] that turns on automatic > >> validation of web.xml against the XML schema specified in that file. > >> > >> (Personally, I usually run with > >> org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true > >> and that turns "xmlValidation" on as well). > >> > >> 4. Top-posting is bad. > > > > Again, sorry. In the end I solved it using a Rewritevalve instead of > > web.xml, and I think that may be the more elegant solution. Certainly > > it's cleaner - edit server.xml and add one file, rewrite.config. That > > takes care of everywhere; both the static pages I started wanting to > > fix, and also the servlet application which I discovered could be > > forced to run http when I was testing. This fixes all. > > > > One last point. I started this particular application for a client > > back in early 2001. At that time I was considered a maverick for > > choosing open source (Tomcat, MySQL) over the then-ubiquitous > > proprietary solutions "everyone" was using. I even got to speak at > > Unix user groups at the time, and even spoke at a CIPS meeting in > > August 2001 (Montreal, PQ, Canada) on the use of open source for > > enterprise solutions. > > > > Mostly folks simply didn't want to believe it could be done. > > > > Fast forward to 2019, when Tomcat & Mysql/MariaDB are now often the > > ubiquitous choices, with proprietary solutions are used mostly where > > upper management has bought the FUD. > > > > A lot has changed in Tomcat in that time; in Unix as well. I started > > with Solaris 8, then Solaris 10, and more recently Ubuntu. I love the > > way things have gotten better. > > > > More than that, I try to "keep up" with changes in security and > > overall robustness and best practices. I did just update from Tomcat > > 8.5.41 to 9.0.22 on Wednesday. It went without a hitch and took about > > 30 minutes total, including testing on the devel server. Basically it > > was easy because I try and keep things up to date. > > > > But... there are still places where legacy code lives in the > > application. Sadly, I'm one developer and it was a pretty big system. > > I tend to be proactive, but only if I think the benefit can really > > justify the time spent figuring it all out. > > > > Cheers, > > > > -Richard > > > >> [1] http://tomcat.apache.org/tomcat-9.0-doc/config/context.html > >> > >> Best regards, > >> Konstantin Kolinko > >> > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > -- > This communication is intended for the use of the recipient to whom it is > addressed, and may contain confidential, personal, and or privileged > information. Please contact us immediately if you are not the intended > recipient of this communication, and do not copy, distribute, or take action > relying on it. Any communications received in error, or subsequent reply, > should be deleted or destroyed. > --- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
