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.
---

Reply via email to