Re: Using HTTP 1.1 over a configured HTTP2 Connector

2024-10-04 Thread Anurag Sharma
HI Mark And Christopher,

Apologies for the late response,

Tomcat act as a reverse proxy to 3rd party legacy system.   We have recently 
upgraded Tomcat to use HTTP/2 protocol; this causes the legacy system not to 
render and get an error message when rendering.  Tomcat application war acts as 
a reverse proxy (which means all requests hit the web app then we have Camel 
Proxy to proxy to the endpoint).

Browser-->HTT2-->Tomcat Web App (Reverse Proxy) -->HTT1.1 --> 3rd Party UI

Since Tomcat is configured with HTTP protocol, the browser automatically 
negotiates the http2 protocol.  Is there any way to configure some path ( 
/context-path/XXX)  would still needs to be HTTP 1.1.

Currently, the only option is for us to open different connector ports strictly 
with HTTP 1.1 and have traffic land here.  Is there any better approach for 
this ?

Thanks and Regards,
Anurag Sharma

From: Mark Thomas 
Date: Tuesday, October 1, 2024 at 5:38 AM
To: users@tomcat.apache.org 
Subject: Re: Using HTTP 1.1 over a configured HTTP2 Connector
CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


On 01/10/2024 06:15, Anurag Sharma wrote:
> Dear Tomcat Team,
>
> I hope this message finds you well.
>
> I am currently facing a challenge regarding the use of HTTP/1.1 for specific 
> API endpoints within a servlet configured for HTTP/2. My browser defaults to 
> HTTP/2, which complicates the situation as I need to proxy some APIs to a 
> server that only supports HTTP/1.1.
> Is there a workaround available to enforce HTTP/1.1 for these particular 
> endpoints?

It isn't clear from the above which component needs to talk to which
using what protocol.

Servlets don't care whether the request is received via HTTP/1.1 or HTTP/2.

Tomcat will happily process requests for the same servlet using HTTP/1.1
or HTTP/2 depending on client support.

Outgoing requests from Tomcat to external services are outside of the
control of Tomcat and are entirely an application concern.

Can you be more precise about what the problem is?

Mark


>
> Here is out server.xml config. All request from our app is http2 protocol.
>
>
>  protocol="org.apache.coyote.http11.Http11NioProtocol"
>
> relaxedPathChars="[\\]^`{|}" relaxedQueryChars="[\\]^`{|}"
>
> address="${tomcat.address}" minSpareThreads="100"  
> maxThreads="200" SSLEnabled="true"
>
> scheme="https" secure="true" maxSwallowSize="-1" 
> maxPostSize="-1">
>
>   readTimeout="5" streamReadTimeout ="-1" streamWriteTimeout="-1"
>
>  overheadContinuationThreshold="0" overheadDataThreshold="0" 
> overheadWindowUpdateThreshold="0"/>
>
>
>   ciphers="${tomcat.ciphers}">
>
>   certificateKeystoreFile="/var/versa/vnms/data/certs/tomcat_keystore.jks"
>
>   certificateKeystorePassword="${keystore.password}"
>
>   certificateKeyPassword="${key.password}"
>
>   certificateKeystoreType="PKCS12" />
>
>  
>
>  
>
>
> Thank you so much for your help.
>
>
>
> Thanks and Regards,
> Anurag Sharma
>


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


Re: net::ERR_HTTP2_PROTOCOL_ERROR with 10.1.30

2024-10-04 Thread Ahmed Ashour
 > How rare? Once in how many requests? Can you trigger this via automated 
 > testing e.g. with wrk?
After working for some time (from 10 minutes to an hour), making a request to a 
page (with subsequent JS/images) every one minute, the issue is shown, happens 
on Chrome and Brave.
The requests with wrk are all successful, tested for one hour, using the 
default settings.
Background:- There is a Tomcat server which is restarted daily, to clean the 
auto deploy of the applications.- Three members have seen the issue, in the 
last 3 days.- The main application is protected by basic authentication- Once 
the issue happens, even the sample non-protected application (html/js) is not 
accessible.

> Does setting discardRequestsAndResponses="true" help at all?

No, it doesn't.
The settings now are:


which still gives the error.
The current workaround is to remove the UpgradeProtocol element.

I wonder if low-level logs, or network sniffing can help, as it is a secure 
connection.
Thanks,Ahmed