Hi Chris,

Thank you so much for your explanation. I will try these options.

Do server and example both resolve to the same IP?
        -yes

So I need follow both 4a/b and 5a/b steps here or any of them ?

If I setup exactly by using below steps , then I should access both the
urls right ? https://server.lbg.com:8443/towl and https://example.lbg.com

I will configure and if I face any issues I will write to you.

Thanks,
Lavanya


On Thursday, May 9, 2024, Christopher Schultz <ch...@christopherschultz.net>
wrote:

> Lavanya,
>
> On 5/9/24 02:58, lavanya tech wrote:
>
>> Just giving background again of this topic again.
>>
>> 1) The application team who is working they wanted to access the url
>> https://server.lbg.com:8443/towl —> which should redirect or point to
>> https://example.lbg.com
>>
>> Is that a typo? You want specifically https://server.lbg.com/towl and
>> https://example.lbg.com/ to point to your application?
>>                — It’s not the Typo the requirements are still the same.
>>
>
> Okay.
>
> Do server and example both resolve to the same IP?
>
> 2) Hence I added firewall rule to redirect port 443 to 8443. And the url
>> https://example.lbg.com started working but its pointing to
>> https://server.lbg.com:8443 indeed and not https://server.lbg.com:8443/to
>> wl
>>
>> But then they wanted the point 1 to have it. If I understood correctly. So
>> basically to achieve this we wanted a reverse proxy setup ?
>>
>> I didnot define any additional host in server.xml file on just left to
>> default to  local host.
>>
>
> Here's what you have to do in order to support this odd configuration.
>
> 1. Configure your firewall to route port 443 -> 8443. I suspect this is
> already done.
>
> 2. Deploy Tomcat on server.lbg.com with a <Connector> on port 8443. This
> is the default, so there shouldn't be anything to do. I suspect this is
> already done. You should set proxyPort="443" and proxyName="
> example.lbg.com" in your <Connector>. This will ensure that any URLs
> generated by Tomcat or your application will point to
> https://example.lbg.com/ and not to server.lbg.com or have a port number
> or whatever.
>
> 3. Re-name your application directory or WAR file from towl -> ROOT (upper
> case is important). So if you have tomcat/webapps/towl re-name that to
> tomcat/webapps/ROOT or if you have tomcat/webapps/towl.war re-name that to
> tomcat/webapps/ROOT.war.
>
> The last thing to do is get /towl to re-direct to /. There are a few ways
> of doing that.
>
> 4a. Configure your application (now called ROOT and deployed on / and not
> /towl anymore) to handle the /towl URL and specifically redirect this back
> to /. This is oddly specific and has the application trying to redirect to
> itself which is weird.
>
> 4b. Create a new application called towl or towl.war which will be
> deployed on /towl and have THAT redirect to /. I think this is cleaner
> because you can call the application anything you'd like and it will still
> work. You don't have to match URL patterns yourself, you just re-name the
> WAR file if you suddenly want to use /towl2 instead of /towl.
>
> There are several ways to redirect.
>
> 5a. Use the rewrite valve and map /(*) to (global redirect) /\1. A few
> notes: (1) the (*) means "capture this string" and \1 means "put the string
> back. This allows you to redirect /towl/foo/bar to /foo/bar instead of
> losing the /foo/bar. This syntax may not be perfect, adapt it to your
> needs. (2) Remember that the towl application is deployed on /towl so you
> don't want to redirect /towl/foo/bar you only want redirect /foo/bar since
> the URL will be relative to the current context (/towl). Got that? Finally,
> (3) you need to use a global redirect that does *NOT* redirect back to the
> /towl application. Normally, if you redirect to /foo you'll get an
> application-relative redirect from something like a rewrite
> valve/filter/whatever. Take care to redirect relative to the SERVER and not
> to the application.
>
> 5b. Write your own servlet to do a specific redirect.
>
> I hope that helps,
> -chris
>
> On Wednesday, May 8, 2024, Christopher Schultz <
>> ch...@christopherschultz.net>
>> wrote:
>>
>> Lavanya,
>>>
>>> On 5/8/24 06:48, lavanya tech wrote:
>>>
>>> I figured out how I can it make it work with 443. Now the URls are
>>>> working.
>>>> I added iptables route 443 to 8443 and it started working.
>>>>
>>>> nslookup example.lbg.com
>>>>
>>>> Non-authoritative answer:
>>>> Name:    server.lbg.com
>>>> Address:  192.168.200.105
>>>> Aliases:  example.lbg.com
>>>>
>>>>
>>>> I have some application towl running with apache tomcat. I have the
>>>> below
>>>> URLs working.
>>>>
>>>> https://server.lbg.com:8443/towl
>>>> https://server.lbg.com
>>>> https://example.lbg.com
>>>> https://example.lbg.com/towl
>>>>
>>>>
>>>> Now i wanted to disable the url https://example.lbg.com/towl and
>>>> https://server.lbg.com and access only the other remaining two.
>>>>
>>>>
>>>
>>
>>
>>> I would *highly* recommend that you pick either /towl or / and not try to
>>> do both, unless you want to deploy the application twice (which is fine,
>>> just deploy towl.war and ROOT.war as copies of each other). If you try to
>>> re-write /towl to / or / to /towl, you'll find you spend the rest of your
>>> days tracking-down edge-cases and "fixing" them -- likely making things
>>> confusing and, probably, worse.
>>>
>>> In the end our goal to makesure that the links are not  always dead as
>>> soon
>>>
>>>> as the towl is moved to a new machine. Can you pelase assit me how to do
>>>> that?
>>>>
>>>>
>>> The goal should be that "moving" the application only means changing DNS
>>> and everything else works as expected.
>>>
>>> If you:
>>>
>>> 1. Deploy the application with a single context (e.g. /towl, which I
>>> recommend)
>>>
>>> 2. Re-direct / to /towl (this requires a reverse-proxy or a ROOT
>>> application that does nothing but redirect ; my personal preference)
>>>
>>> 3. Do not define any <Host> other than "localhost" and make it the
>>> default. Do not bother with any <Alias> elements since they are not
>>> necessary.
>>>
>>> Moving the application should only require that you:
>>>
>>> 4. Deploy the same application with the same configuration in the new
>>> location
>>>
>>> 5. Change DNS to point example.lbg.com and server.lbg.com to the new
>>> location of the service
>>>
>>> Hope that helps,
>>> -chris
>>>
>>> On Tue, Apr 30, 2024 at 5:44 PM Christopher Schultz <
>>> ch...@christopherschultz.net> wrote:
>>>
>>> Lavanya,
>>>
>>> On 4/30/24 07:10, lavanya tech wrote:
>>>
>>> Can you tell me how to do the below ? How should I setup Tomcat in
>>> server.xml ?
>>>
>>>
>>> If you want to use port 443 (the default port for HTTPS) then you will
>>> need to change Tomcat to bind to port 443 (if that's allowed on your OS)
>>> or arrange to have port 443 routed to port 8443. You may need additional
>>> configuration in Tomcat (specifically: proxyPort) to avoid having Tomcat
>>> generate URLs with ":8443" in them.
>>>
>>> Looking forward to your reply.
>>>
>>>
>>> If Tomcat is listening on port 8443 then you will need to include that
>>> in your URL, period. If you want to allow URLs without a port number,
>>> you will have to arrange to have something listening on port 443.
>>>
>>> On Windows, Tomcat can listen directly on port 443. On UNIX and
>>> UNIX-like systems, you won't be able to do this without running Tomcat
>>> as root WHICH YOU ABSOLUTELY SHOULD NOT DO.
>>>
>>> There are other ways to get port 443 working, but I'll need to know more
>>> about your environment. The port issue is "easier" than figuring out
>>> whatever is going on with your DNS, aliases, etc. so I would recommend
>>> we fix one thing at a time.
>>>
>>> -chris
>>>
>>> On Mon, Apr 29, 2024 at 2:03 PM lavanya tech <lavanyatech...@gmail.com>
>>> wrote:
>>>
>>> Hi Chris,
>>>
>>> There is no issues with browser, because I tested with different
>>>
>>> browsers
>>>
>>> and it all works fine. I am sure that there is no issue with the
>>> certificate.
>>>     Because I was able to establish successful connections with port
>>>
>>> 8443, it
>>>
>>> just doesnot work with out port
>>>
>>>     curl  https://example.lbg.com/towl
>>> curl: (56) Received HTTP code 504 from proxy after CONNECT
>>> curl: (56) Received HTTP code 504 from proxy after CONNECT
>>>
>>>
>>> If you want to use port 443 (the default port for HTTPS) then you will
>>> need to change Tomcat to bind to port 443 (if that's allowed on your OS)
>>> or arrange to have port 443 routed to port 8443. You may need additional
>>> configuration in Tomcat (specifically: proxyPort) to avoid having Tomcat
>>> generate URLs with ":8443" in them.
>>>
>>> <Connector port="443" protocol="HTTP/1.1"
>>>               connectionTimeout="20000"
>>>               redirectPort="8443"
>>>               maxThreads="150"
>>>               scheme="https" secure="true" SSLEnabled="true"
>>>               keystoreFile="path_to_your_keystore_file"
>>>               keystorePass="your_keystore_password"
>>>               keystoreType="PKCS12"
>>>               clientAuth="false" sslProtocol="TLS"
>>>               proxyPort="443"/>
>>>
>>> should i use connect port like the above ?  But you mentioned before we
>>> dont need any configuration changes. Please clarify I am not able to
>>>
>>> figure
>>>
>>> this out and I have this issue many days pending. How to make it work
>>>
>>> with
>>>
>>> port 8443 and with out port
>>>
>>> Also I wanted to use weburl with alias name permanently instead of the
>>> hostname. How can I achieve both
>>>
>>> Thanks,
>>> Lavanya
>>>
>>>
>>>      -->
>>>
>>>
>>> On Fri, Apr 26, 2024 at 9:28 PM Christopher Schultz <
>>> ch...@christopherschultz.net> wrote:
>>>
>>> Lavanya,
>>>
>>> On 4/25/24 07:24, lavanya tech wrote:
>>>
>>> Hi Chris,
>>>
>>> One question / doubt:
>>>
>>> As I mentioned earlier, the below URLS already working in the browser
>>>
>>> https://server.lbg.com:8443/towl
>>> https://example.lbg.com:8443/towl -> redirect ( which means when I
>>>
>>> hit in
>>>
>>> browser) it points to https://server.lbg.com:8443/towl ---> To be
>>>
>>> frank,
>>>
>>> even I donot need redirect here, not sure why it redirects.
>>>
>>> My question is why its working even though SAN is not registered with
>>>
>>> the
>>>
>>> certificate ? It doesnot even throw warning in the browser.
>>>
>>>
>>> I'm not sure. Is it possible you have dismissed this error in the past
>>> and the browser is remembering that? Try this with a different web
>>> browser or maybe with curl from the command-line to see what happens.
>>>
>>> Why https://server.lbg.com/towl or https://example.lbg.com/towl -->
>>>
>>> How it
>>>
>>> should work with New SAN certificate ?
>>>
>>>
>>> You don't need to worry about the port number or application name, only
>>> the hostname is a part of the SAN.
>>>
>>> -chris
>>>
>>> On Thu, Apr 25, 2024 at 10:16 AM lavanya tech <
>>>
>>> lavanyatech...@gmail.com
>>>
>>>
>>> wrote:
>>>
>>> Hi Chris,
>>>
>>>
>>> Thanks I will request new certificate with SANs and I will try to fix
>>>
>>> the
>>>
>>> things from our end.
>>>
>>> Best Regards,
>>> Lavanya
>>>
>>> On Wed, Apr 24, 2024 at 11:12 PM Christopher Schultz <
>>> ch...@christopherschultz.net> wrote:
>>>
>>> Lavanya,
>>>
>>> On 4/24/24 15:39, lavanya tech wrote:
>>>
>>> Local host means the machine i am logged in to server.lbg.com
>>>
>>> You are right, example.lbg.com is CNAME record.
>>>
>>>
>>> Okay, thanks for clearing that up.
>>>
>>> I dont have any SAN configured for the certificate. The certificate
>>>
>>> is
>>>
>>> requested for only server.lbg.com
>>>
>>>
>>> You will never be able to make a secure request to anything other
>>>
>>> than
>>>
>>> server.lbg.com without seeing an error. I highly recommend adding
>>>
>>> the
>>>
>>> other hostname as a SAN to your certificate if you really want to
>>> support this.
>>>
>>> Even if you wanted https://example.lbg.com/whatever to return an
>>>
>>> HTTP
>>>
>>> 302 redirect to https://server.lbg.com/whatever, the user would
>>>
>>> see a
>>>
>>> certificate hostname mismatch error which is ugly. It's best to make
>>>
>>> it
>>>
>>> work without users seeing ugly things.
>>>
>>> So if i just request new certificate with SAN it should work ? If
>>>
>>> yes, I
>>>
>>> will request for it and follow your steps as below suggested.
>>>
>>>
>>> Yes, it should.
>>>
>>> Should i use CName record or DNS? Does it make difference?
>>>
>>>
>>> CNAME *is* DNS.
>>>
>>> Whenever possible, use hostnames and not IP addresses as SANs. It's
>>>
>>> more
>>>
>>> flexible that way, and users get to see hostnames instead of IP
>>>
>>> addresses.
>>>
>>>
>>> -chris
>>>
>>> On Wednesday, April 24, 2024, Christopher Schultz <
>>> ch...@christopherschultz.net> wrote:
>>>
>>> Lavanya,
>>>
>>> On 4/24/24 07:37, lavanya tech wrote:
>>>
>>> Sorry I understood wrongly here with regards to my environment,
>>>
>>> Let me
>>>
>>> start from the beginning. I donot want to use redirect at all. I
>>>
>>> simply
>>>
>>> wanted to force apache tomcat to use both localhost and dns name
>>>
>>> of
>>>
>>> the
>>>
>>> localhost via url.
>>>
>>>
>>> When you say "force" what do you mean?
>>>
>>> When you say "use both localhost and DNS name" what do you mean?
>>>
>>> When you say "localhost" do you mean 127.0.0.1 or "the machine I'm
>>> logged-into right now"?
>>>
>>> I have DNS resollution as below.
>>>
>>>
>>> server.lbg.com --> localhost
>>>
>>>
>>> Is that a CNAME record?
>>>
>>> nslookup server.lbg.com (localhost)
>>>
>>> Name:    server.lbg.com
>>> Address:  192.168.100.20
>>> alias: example.lbg.com
>>>
>>>
>>> That's a weird DNS response. The DNS name "localhost" should
>>>
>>> *always*
>>>
>>> return 127.0.0.1 for IPv4 and ::1 for IPv6. It shouldn't return
>>> 191.168.100.20.
>>>
>>> We have working the below urls working:
>>>
>>> https://server.lbg.com:8443/towl
>>> https://example.lbg.com:8443/towl --> redirects to
>>>
>>>
>>> What do you mean "redirect"? Does it return a 30x response that
>>>
>>> causes
>>>
>>> the
>>>
>>> browser to make a new request to \/
>>>
>>> https://server.lbg.com:8443/towl  --> still works --> we have SSL
>>>
>>> configured for the same but this SSL certificate doesnot have
>>>
>>> additional
>>>
>>> DNS setup.
>>>
>>>
>>> What SANs are in your certificate? How many certificates do you
>>>
>>> have?
>>>
>>>
>>> But I would need to somehow  access https://example.lbg.com -->
>>>
>>> which
>>>
>>> means
>>> I would need to access via 443 here ?
>>>
>>>
>>> I'm so confused. What needs to access what?
>>>
>>> I tried to adding the below to  server.xml as below, but that
>>>
>>> doesnot
>>>
>>> seems
>>>
>>> to work.
>>>
>>>           <Connector port="80"
>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>>                  connectionTimeout="20000"
>>>                  redirectPort="443" />
>>>
>>>
>>> This will only redirect (HTTP 302) requests to
>>>
>>> http://yourhost/anything
>>>
>>> to https://yourhost/anything *if the application specifically
>>>
>>> requests
>>>
>>> CONFIDENTIAL transport*. It doesn't just redirect everything by
>>>
>>> default. If
>>>
>>> you want it to redirect everything, you'll need to set that up
>>>
>>> e.g.
>>>
>>> using
>>>
>>> RewriteValve. There are other options, too.
>>>
>>> Do i need additional SSL certificate for the
>>>
>>> https://example.lbg.com
>>>
>>> to
>>>
>>> make it work ?
>>>
>>>
>>> If you don't want your browser to complain, you will need at least
>>>
>>> one
>>>
>>> TLS
>>>
>>> certificate that contains every Subject Alternative Name (SAN) for
>>>
>>> every
>>>
>>> possible hostname you expect to use with this service. You ca do
>>>
>>> it
>>>
>>> with
>>>
>>> multiple certificates as well, but a single cert with multiple
>>>
>>> SANs
>>>
>>> is
>>>
>>> less
>>>
>>> work.
>>>
>>> Do i need to set up an additional web server for this like apache
>>>
>>> or
>>>
>>> nginx
>>>
>>> for redirecting requests?
>>>
>>>
>>> No.
>>>
>>> Please stop saying "redirect" because it sounds like you almost
>>>
>>> never
>>>
>>> mean
>>>
>>> "HTTP 30x redirect" and that's confusing everything.
>>>
>>> I *think* you only need the following:
>>>
>>> 1. A TLS certificate with the following SANs:
>>>
>>>        * server.lbg.com
>>>        * example.lbg.com
>>>        * localhost (you shouldn't do this)
>>>
>>> 2. DNS configured for all hostnames:
>>>
>>>        * server.lbg.com -> A 192.168.100.20
>>>        * example.lgb.com -> A 192.168.100.20
>>>
>>> 3. Tomcat configured with a single <Host> which is the default
>>>
>>> virtual
>>>
>>> host. Note that this is the *default Tomcat configuration* and
>>>
>>> doesn't
>>>
>>> need
>>>
>>> to be changed from the default.
>>>
>>> 4. Tomcat configured with your certificate like this:
>>>
>>>         <Connector ...
>>>            SSLEnabled="true">
>>>           <SSLHostConfig>
>>>             <Certificate
>>>                 certificateFile="/path/to/your/cert.crt"
>>>                 certificateKeyFile="/path/to/your/key.pem" />
>>>             <!-- You may need certificateKeyPassword in
>>>
>>> <Certificate>
>>>
>>> -->
>>>
>>>           </SSLHostConfig>
>>>         </Connector>
>>>
>>> If your SANs are configured properly, this should allow you to
>>>
>>> connect
>>>
>>> using any of these URLs:
>>>
>>> $ curl https://server.lbg.com/towl/login.jsp
>>>
>>>        (returns login page)
>>>
>>> $ curl https://example.lbg.com/towl/login.jsp
>>>
>>>        (returns login page)
>>>
>>> If your application's web.xml contains something like this:
>>>
>>>        <security-constraint>
>>>          <web-resource-collection>
>>>            <web-resource-name>theapp</web-resource-name>
>>>            <url-pattern>/*</url-pattern>
>>>          </web-resource-collection>
>>>          <user-data-constraint>
>>>            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>>>          </user-data-constraint>
>>>        </security-constraint>
>>>
>>> ... then these URLs insecure HTTP URLs should redirect your
>>>
>>> clients:
>>>
>>>
>>> $ curl http://server.lbg.com/towl/login.jsp
>>>
>>>        (returns HTTP 302 redirect to
>>>
>>> https://server.lbg.com/towl/login.jsp
>>>
>>> )
>>>
>>>
>>> $ curl https://server.lbg.com/towl/login.jsp
>>>
>>>        (returns HTTP 302 redirect to
>>>
>>> https://example.lbg.com/towl/login.jsp)
>>>
>>>
>>> I don't think you need any use of the RewriteValve unless you want
>>>
>>> to
>>>
>>> handle sending HTTP 302 redirect responses to insecure requests
>>>
>>> without
>>>
>>> specifying the CONFIDENTIAL transport-guarantee in your
>>>
>>> application's
>>>
>>> web.xml file. But I don't see any reason NOT to have that in
>>>
>>> there.
>>>
>>>
>>> -chris
>>>
>>> On Tue, Apr 23, 2024 at 10:52 PM Christopher Schultz <
>>>
>>> ch...@christopherschultz.net> wrote:
>>>
>>> Lavanya,
>>>
>>>
>>> On 4/22/24 05:21, lavanya tech wrote:
>>>
>>> Could you please explain, what you exactly mean ? So here
>>>
>>> redirect
>>>
>>> is
>>>
>>>
>>> not a
>>>
>>> solution right ?
>>>
>>>
>>> Redirecting is fine.
>>>
>>> Perhaps you should take a step back and decide: what do you
>>>
>>> actually
>>>
>>> want, here? You might be trying to solve problem X by applying
>>>
>>> solution
>>>
>>> Y, and you've already decided that solution Y is correct so you
>>>
>>> are
>>>
>>> trying to get help with that.
>>>
>>> Perhaps ask for help with Problem X?
>>>
>>> For example, "I don't want users to have to type the name of my
>>> application to reach it so I want example.com/ to go to my
>>>
>>> application
>>>
>>> instead of example.com/myapp/".
>>>
>>> Or, "I have multiple domains and I want all of them to redirect
>>>
>>> to
>>>
>>> the
>>>
>>> canonical domain example.com and to go to me web application
>>>
>>> /myapp
>>>
>>> so
>>>
>>> everything goes to example.com/myapp/".
>>>
>>> "You'd have to use a glob/regex if
>>>
>>> you wanted to check for [anything and maybe nothing.]
>>>
>>> example.com
>>>
>>> ."
>>>
>>>
>>>
>>> There is nothing in your configuration or question that suggests
>>>
>>> that
>>>
>>> the hostname in the request is relevant, but you are making it a
>>> *requirement* that the request contains a specific Host header.
>>>
>>> IF
>>>
>>> you
>>>
>>> don't actually need that, why do you have it?
>>>
>>> -chris
>>>
>>> On Fri, Apr 19, 2024 at 3:03 PM Christopher Schultz <
>>>
>>> ch...@christopherschultz.net> wrote:
>>>
>>> Ammu,
>>>
>>>
>>> On 4/19/24 08:32, lavanya tech wrote:
>>>
>>> Thank you very much. I removed <Host> for example.com as
>>>
>>> well
>>>
>>> as
>>>
>>>
>>> adding
>>>
>>>
>>> an
>>>
>>>
>>> <Alias> in server.xml
>>> I copied context.xml file
>>>
>>> /git/app/apache-tomcat-10.1.11/webapps/towl/META-INF/context.xml
>>>
>>> Removed < in rewrite.config files.
>>>
>>> But still I dont redirect the URL.
>>>
>>>
>>> If you have <Context> in server.xml and also your application
>>>
>>> in
>>>
>>> the
>>>
>>> webapps/ directory, then you will be double-deploying your
>>>
>>> application.
>>>
>>>
>>> Re-name /git/app/apache-tomcat-10.1.11/webapps/towl/ to be
>>> /git/app/apache-tomcat-10.1.11/webapps/ROOT (the capitals are
>>> important)
>>> and remove the <Context> element from your server.xml.
>>>
>>> Then start your server and read the logs.
>>>
>>> *nslookup alias.example.com <http://alias.example.com>
>>>
>>> gives-->Non-authoritative answer:Name:     www.example.com
>>> <http://www.example.com>Address:  192.168.200.10Aliases:
>>>
>>> alias.example.com
>>>
>>> <http://alias.example.com>*
>>>
>>>
>>> Just to give some information here, *www.example.com
>>> <http://www.example.com>* has alias* "alias.example.com
>>> <http://alias.example.com>"*
>>> But https://www.example.com:7777/example --> works fine with
>>>
>>> out
>>>
>>>
>>> issues
>>>
>>>
>>> but
>>>
>>>
>>> the alias doesnot works (https://alias.example.com)
>>> So i am not sure if the redirect url helps or if its correct
>>>
>>>
>>> Your rewrite configuration says that you have to be using host
>>> "example.com" but your request goes to www.example.com. Your
>>> configuration should only redirect a request such as:
>>>
>>> $ curl -v http://example.com:7777/something
>>>
>>> HTTP/1.1 301 Moved Permanently
>>> ...
>>> Location: https://www.example.com:7777/example
>>>
>>> If you make a request like:
>>>
>>> $ curl -v http://www.example.com:7777/something
>>>
>>> I wouldn't expect a redirect because of your "host" condition.
>>>
>>> The
>>>
>>> "%{HTTP_HOST} example.com" looks at the entire Host header
>>>
>>> and
>>>
>>> not
>>>
>>> just
>>> anything that ends in "example.com". You'd have to use a
>>>
>>> glob/regex if
>>>
>>> you wanted to check for [anything and maybe nothing.]
>>>
>>> example.com.
>>>
>>>
>>> You'd also have to make sure that your application is serving
>>>
>>> responses
>>>
>>> to requests to / which is why I'm recommending you use the
>>>
>>> ROOT
>>>
>>> web
>>>
>>> application name instead of "towl".
>>>
>>> -chris
>>>
>>> On Fri, Apr 19, 2024 at 1:21 PM Christopher Schultz <
>>>
>>> ch...@christopherschultz.net> wrote:
>>>
>>> Ammu,
>>>
>>>
>>> On 4/18/24 09:34, lavanya tech wrote:
>>>
>>> I am attaching server.xml and context.xml and
>>>
>>> rewrite.config
>>>
>>> files.
>>>
>>> The paths are
>>>
>>> /git/app/apache-tomcat-10.1.11/webapps/towl/context.xml
>>> <Context>
>>>              <Valve
>>>
>>> className="org.apache.catalina.valves.rewrite.RewriteValve"
>>>
>>>
>>> />
>>>
>>>
>>>              <!-- Other context configuration -->
>>> </Context>
>>>
>>>
>>> This file ^^^ is in the wrong place. It should be in
>>>
>>> /git/app/apache-tomcat-10.1.11/webapps/towl/META-INF/context.xml
>>>
>>>
>>>
>>> /git/app/apache-tomcat-10.1.11/webapps/towl/WEB-INF/rewrite.config
>>>
>>>
>>> <RewriteCond %{HTTP_HOST} example.com [NC]
>>> <RewriteRule ^/(.*)$ https://www.example.com:7777/example
>>>
>>> [R=301,L]
>>>
>>>
>>>
>>> Why do you have < symbols at the beginning of these lines?
>>>
>>> server.xml
>>>
>>>
>>>          > [...]
>>>
>>>
>>>
>>>                <Host name="example.com" appBase="webapps"
>>>
>>> unpackWARs="true"
>>>
>>>
>>> autoDeploy="true">
>>>
>>>                    <Context path="" docBase="towl" />
>>>
>>>
>>> It's best not to define any <Context> in server.xml. I would
>>>
>>> remove
>>>
>>>
>>> this
>>>
>>>
>>> <Context> entirely and allow Tomcat to auto-reploy from your
>>>
>>> webapps/towl directory. If you need this application to be
>>>
>>> deployed
>>>
>>> as
>>> the ROOT context (on / and not /towl) then you should
>>>
>>> re-name
>>>
>>> /git/app/apache-tomcat-10.1.11/webapps/towl to
>>> /git/app/apache-tomcat-10.1.11/webapps/ROOT
>>>
>>> You also don't need a <Host> for example.com as well as
>>>
>>> adding
>>>
>>> an
>>>
>>> <Alias> for the same domain (though this is probably to
>>>
>>> anonymize the
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Reply via email to