Re: Regarding Tomcat url redirection
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. 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 > > 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.10
Re: Tomcat closes connections on unexpected status codes
Chris,
On Fri, Apr 19, 2024 at 4:40 AM Christopher Schultz
wrote:
>
> Pawel,
>
> On 4/18/24 20:21, Pawel Veselov wrote:
> >> On 18/04/2024 15:18, Stefan Ansing wrote:
> >>> Hi Rémy, Mark,
> >>> I just want to make sure that we’re understanding each other. I can see
> >>> that the connection needs to be closed in certain conditions to prevent
> >>> request smuggling attacks. I certainly don’t want to change that
> >>> behaviour.
> >>> However, I’m facing a scenario where an application is responding to a
> >>> valid request (from HTTP perspective), with a valid response using these
> >>> status codes (more specifically status codes 400 and 500).
> >> If the request is a valid HTTP request then a 400 status doesn't seem
> >> appropriate to me.
> >
> > It's by now, however, a de-facto standard. Every time I try to
> > determine "which HTTP response should I send back in case of issues
> > with the data", I find myself scrolling through the list of defined
> > codes and not finding anything that would otherwise fit. The HTTP
> > spec states what should the server do in case of HTTP protocol errors
> > (respond with an appropriate 4xx), but that's all that the spec
> > covers for the protocol, and it doesn't prohibit use of 400 for
> > application-level errors. Out of the entire 4xx codes, 400 is (maybe
> > also 414?) the only one that is used for protocol problems, others
> > are for application level errors, but they are very specific and
> > limiting (IMHO).
> When you say "protocol problems", what protocol are you referring to?
In this instance, I meant the actual problems with the HTTP protocol contents.
400 is normally returned by the container because it couldn't
understand the HTTP.
414 is probably as well (because container ran out of maximum
available space to read
in the URI). The rest of the error codes are expected to be produced by the
application, but they were devised for that application being a web server.
> Because if the request is readable and syntactically correct, there is
> no protocol problem. Everything else is ... something else. If you are
> establishing a protocol ON TOP OF HTTP then it's a violation of whatever
> protocol THAT is, not HTTP. So it's better to return { "error" : "Foo
> Protocol violation" } with an appropriate HTTP status code, possibly
> even *200*.
Yes. But (again, assuming web-service-like implementation), the application can
return other HTTP codes for other data (on top of HTTP) issues, i.e., when an
endpoint is not found, 404, when data type is wrong - 415; there are also those
exuberant codes like 409 and 410. So, on the surface, it looks like
the application
can use 4xx codes to signal an error, so one can lay down a contract that says
"2xx means OK response from the application's perspective, and if there is an
error, we'll return some 4xx code", but there *was* (see below) no good 4xx
code for saying "Hey, you forgot a JSON property in your input".
You're right, it probably should have been 2xx, but it's also cringy
to say things like
"there are some errors that we will return 4xx for, but for some it will be 2xx,
and here is how you differentiate successful 2xx from error response 2xx".
I did do that in at least one w/s implementation, and had the customer
yell at me for my trouble. This path is also not well supported by standards
like OAS/RAML (last time I checked, at least). The description of the responses
becomes significantly more complicated in this case.
And, again, there is AWS that is a rather large supplier of web services,
and they did decide to use 400 for this. The web-service client still needs
to distinguish between "400 because the header is mangled", or "400 because
a JSON property was missing". The RFC doesn't explicitly limit the use of
400 to HTTP protocol problems, even though all the examples that are listed
in the spec *are* such.
I did look again at the specs just now, and lo and behold, there is now a
code 422. Which, at least on the surface, looks like exactly the code to use
for responding with application-related content problems. It wasn't there in
RFC#7231 (and neither in #2616 or #2068), but #9110 does have it (yet
the language around 400 is still overly broad), which makes it about 2
years old.
Now, of course, existing w/s contracts aren't likely to switch to using that,
but for any new ones I'll certainly consider it.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
