On 05/03/2025 19:19, François Rajotte wrote:
Hi Christopher,
Thanks for your comments.
Regarding the behavior of the non-container thread when an async
request gets cancelled, I don't really care exactly how it's handled.
Currently, my strategy is to let it finish if it had alrea
Hi Christopher,
Thanks for your comments.
Regarding the behavior of the non-container thread when an async
request gets cancelled, I don't really care exactly how it's handled.
Currently, my strategy is to let it finish if it had already started
processing when the request got can
e
thread and we want to send the response.
At any time, tomcat may decide to "complete" the request and recycle
the HttpRequest and HttpResponse objects. For example, the socket
could be disconnected or timed out. Tomcat notifies the servlet that
this is happening by calling the AsyncL
mcat may decide to "complete" the request and recycle
the HttpRequest and HttpResponse objects. For example, the socket
could be disconnected or timed out. Tomcat notifies the servlet that
this is happening by calling the AsyncListener.onComplete method.
The non-container th
Thanks for the help.
Best regards,
Chris Evans
-Original Message-
From: Christopher Schultz
Sent: Wednesday, February 26, 2025 7:38 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat 10.1.36 Configuration Question: Client Certificate(s)
missing from servlet request object
Robert
andshake
Connector Configuration:
Java:
@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse
response)
File="/home/ubuntu/tomcat/serverCert.pem"
>
> certificateChainFile="/home/ubuntu/tomcat/serverChain.pem"
>
> certificateKeyFile="/home/ubuntu/tomcat/rsaKey.pem"
> type="RSA" />
>
>
extends HttpServlet {
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
System.out.println("HelloServlet");
response.setContentType("text/html");
re
>>> restarted the tomcat service. No luck still, very confused this behavior.
Regards,
DivyaBharathi.S
TCS - Infra Midrange SME
Malaysia Airlines Berhad
From: Christopher Schultz
Sent: Friday, January 17, 2025 8:38 PM
To: users@tomcat.a
ou getting NO OTHER ERRORS on the server side?
-chris
From: Christopher Schultz
Sent: Thursday, January 16, 2025 7:49 PM
To: users@tomcat.apache.org
Subject: Re: REG: FAIL - Deploy Upload Failed, Exception: [Processing of
multipart/form-data request failed.
rocessing of
multipart/form-data request failed. java.net.SocketTimeoutException]
CAUTION! This email originated from outside of MAG
Divyabharathi,
On 1/16/25 9:14 AM, Divyabharathi Sundaram wrote:
> Hi Team,
>
> Tomcat version : 9.0.82 & 9.0.96
> Issue: Not able to deploy from
load Failed, Exception: [Processing of multipart/form-data request failed.
java.net.SocketTimeoutException]
We are encountering deployment issue from tomcat console. When we try to upload the file and
deploy from tomcat console, it throws the error " the site cannot be reached". We
Hi Team,
Tomcat version : 9.0.82 & 9.0.96
Issue: Not able to deploy from tomcat console with http protocol
Error: SEVERE [http-nio-8080-exec-25]
org.apache.catalina.core.ApplicationContext.log HTMLManager: FAIL - Deploy
Upload Failed, Exception: [Processing of multipart/form-data req
hanks and Regards,
Rajendra Rathore
9922701491
-Original Message-
From: Mark Thomas
Sent: Monday, November 18, 2024 4:48 PM
To: Tomcat Users List
Cc: annou...@apache.org; annou...@tomcat.apache.org; Tomcat Developers List
Subject: [SECURITY] CVE-2024-52317 Apache Tomcat - Request a
; annou...@tomcat.apache.org; Tomcat Developers List
Subject: [SECURITY] CVE-2024-52317 Apache Tomcat - Request and/or response
mix-up
CVE-2024-52317 Apache Tomcat - Request and/or response mix-up
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected:
Apache Tomcat 11.0.0
Note: Correction to 10.1.x affected versions
CVE-2024-52317 Apache Tomcat - Request and/or response mix-up
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected:
Apache Tomcat 11.0.0-M23 to 11.0.0-M26
Apache Tomcat 10.1.27 to 10.1.30
Apache Tomcat 9.0.92 to 9.0.95
CVE-2024-52317 Apache Tomcat - Request and/or response mix-up
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected:
Apache Tomcat 11.0.0-M23 to 11.0.0-M26
Apache Tomcat 10.1.7 to 10.1.30
Apache Tomcat 9.0.92 to 9.0.95
Description:
Incorrect recycling of the request and
On 20/10/2024 02:49, Dan McLaughlin wrote:
We use Shibboleth SP, which passes request attributes from Apache over AJP
to Tomcat; after upgrading from Tomcat 10.1 to Tomcat 11, the request
attributes aren't coming over. Does anyone know of anything that changed
in Tomcat 11 that might a
We use Shibboleth SP, which passes request attributes from Apache over AJP
to Tomcat; after upgrading from Tomcat 10.1 to Tomcat 11, the request
attributes aren't coming over. Does anyone know of anything that changed
in Tomcat 11 that might affect request attributes being passed ove
On 17/09/2024 13:46, manjosh ramesh wrote:
Hi Mark,
What is strange is that we are obtaining the cookie by triggering an HTTP
request to a spring-boot application running on Tomcat. The same tomcat server
adds '^M$' at the end of each line in the response.
If we redirect this res
Hi Mark,
What is strange is that we are obtaining the cookie by triggering an HTTP
request to a spring-boot application running on Tomcat. The same tomcat server
adds '^M$' at the end of each line in the response.
If we redirect this response to a file and use a cookie, Tomcat
ongly recommend that anyone considering
one of those options looks carefully at the provider's claims of Tomcat
expertise. Or just upgrade to an ASF supported version.
Because the older tomcat allows this type of request.
Quite possibly. There has been a general tightening up of HTTP r
Hi,ok, so this was a bug in older tomcat release and has been fixed in newer
version, is it? Could you please share the bug id for this change? Because the
older tomcat allows this type of request. Also Our cookie is complient. We are
not able to find what is not complient in our cookie. It
On 04/06/2024 15:37, Christopher Schultz wrote:
On 6/4/24 09:10, Chuck Caldarale wrote:
The problem is the { and } characters.
My reading of RFC 7230 is that { and } /should/ be allowed, but
Tomcat's code rejects them by default.
My reading is as follows:
RFC 9110:
http-URI = "http" ":
Chuck,
On 6/4/24 09:10, Chuck Caldarale wrote:
On Jun 4, 2024, at 06:07, Christopher Schultz
wrote:
04-Jun-2024 09:49:11.448 INFO [http-nio-8080-exec-6]
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request
header
Note: further occurrences of HTTP request
> On Jun 4, 2024, at 06:07, Christopher Schultz
> wrote:
>> 04-Jun-2024 09:49:11.448 INFO [http-nio-8080-exec-6]
>> org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request
>> header
>> Note: further occurrences of HTTP request pa
Christoph,
On 6/4/24 05:49, Christoph Kukulies wrote:
I'm getting these when startig tomcat9:
This is a request, not startup. But it's not important.
04-Jun-2024 09:49:11.448 INFO [http-nio-8080-exec-6]
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP reque
I'm getting these when startig tomcat9:
04-Jun-2024 09:49:11.448 INFO [http-nio-8080-exec-6]
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request
header
Note: further occurrences of HTTP request parsing errors will be logged at
DEBUG
return new ObfuscatedQueryElement();
Where ObfuscatedQueryElement is much like the existing QueryElement with
your additional requirements.
They both would implement AccessLogElement which has access to the
Request object
-Tim
On Fri, Jan 26, 2024 at 7:58 AM Manak Bisht wrote:
> I want to obfuscate
I want to obfuscate values of query params for certain URLs, however, I
would still like to log the request. Therefore, I cannot use the existing
conditionif/conditionunless attributes that AccessLogValve provides.
Sincerely,
Manak Bisht
On Fri, Jan 26, 2024 at 6:18 PM Mark Thomas wrote:
>
On 26/01/2024 10:46, Manak Bisht wrote:
Hi,
I am trying to extend the AccessLogValve to modify logging behaviour for
certain URLs. However, I don't have access to the request object in the
AccessLogValve API. So, I am left with regex matching on the CharArrayWriter
message object. Is th
My bad - AccessLogValve also supports that feature too
- *%{xxx}r* write value of ServletRequest attribute with name xxx (escaped
if required, value ?? if request is null)
https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Access_Logging
-Tim
On Fri, Jan 26, 2024 at 7:23 AM Tim
It depends on what you are trying to accomplish. ExtendedAccessLogValve is
a
little more flexible where you can write out arbitrary request
attributes but still format the request like the standard access
log. So you could have a filter set the value and not need to
write your own access logger
Hi,
I am trying to extend the AccessLogValve to modify logging behaviour for
certain URLs. However, I don't have access to the request object in the
AccessLogValve API. So, I am left with regex matching on the CharArrayWriter
message object. Is there a better way to do this?
Sincerely,
JAVA -tomcat- Request header is too large
CAUTION: This email originated from outside the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe. If you believe this is a phishing email, use the Report to
Cybersecurity icon in Outlook.
Amit,
On 12/11/23 11:32, Amit Pande wrote:
Mark, Chris,
What request ID we're referring to here? Perhaps, I missed some documentation?
How do we enable it?
Request-id is available in Tomcat 11.0 and 10.1 at the moment. Are you
using either of those?
I'm not seeing any docume
Mark, Chris,
What request ID we're referring to here? Perhaps, I missed some documentation?
How do we enable it?
Thanks,
Amit
-Original Message-
From: Mark Thomas
Sent: Monday, December 11, 2023 3:06 AM
To: users@tomcat.apache.org
Subject: Re: JAVA -tomcat- Request header i
On 08/12/2023 22:01, Christopher Schultz wrote:
Are request-ids always allocated, or only if they are "enabled"?
Always allocated.
I think adding the request-id to this exception detail message might be
helpful, even if the request-id hasn't been enabled in the access-log.
-5826]
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP
request header
Note: further occurrences of HTTP request parsing errors will be
logged at DEBUG level.
java.lang.IllegalArgumentException: Request header is too large
at
org.apache.coyote.http11
.Http11Processor.service Error parsing HTTP
request header
Note: further occurrences of HTTP request parsing errors will be
logged at DEBUG level.
java.lang.IllegalArgumentException: Request header is too large
at
org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java:790
Il 07/12/2023 17:51, Mark Thomas ha scritto:
On 07/12/2023 15:37, Ivano Luberti wrote:
Hi, since a few days these errors started showing in my log files:
06-Dec-2023 07:39:56.082 INFO [http-nio-8080-exec-5826]
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP
request
On 07/12/2023 15:37, Ivano Luberti wrote:
Hi, since a few days these errors started showing in my log files:
06-Dec-2023 07:39:56.082 INFO [http-nio-8080-exec-5826]
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP
request header
Note: further occurrences of HTTP request
Hi, since a few days these errors started showing in my log files:
06-Dec-2023 07:39:56.082 INFO [http-nio-8080-exec-5826]
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP
request header
Note: further occurrences of HTTP request parsing errors will be
logged at DEBUG level
Graham,
On 11/28/23 14:11, Graham Leggett wrote:
On 28 Nov 2023, at 18:42, Christopher Schultz
wrote:
In your debugger, when you break-on-exception, what happens if you allow the
exception to propagate up to the first exception-handler? Does Tomcat swallow
the exception? Or it it caught el
Graham,
On 11/29/23 05:01, Graham Leggett wrote:
On 28 Nov 2023, at 21:10, Graham Leggett wrote:
So the reason we get a 400 Bad Request with no error detail is that we arrive
at this line with throwable set to null:
https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/catalina
On 28 Nov 2023, at 21:10, Graham Leggett wrote:
> So the reason we get a 400 Bad Request with no error detail is that we arrive
> at this line with throwable set to null:
>
> https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/catalina/valves/ErrorReportValve.java#L129
On 29 Nov 2023, at 07:18, Thomas Hoffmann (Speed4Trade GmbH)
wrote:
>> I’m in dependency hell - java8 to java17, JAXB as used by Jersey2 broke. No
>> idea why, but an internal Oracle implementation is hardcoded somewhere.
>>
>> java.lang.ClassNotFoundException: oracle.xml.jaxp.JXSAXParserFactor
Hello Graham,
> -Ursprüngliche Nachricht-
> Von: Graham Leggett
> Gesendet: Dienstag, 28. November 2023 20:12
> An: Tomcat Users List
> Betreff: Re: 400 Bad Request - where do I find the detailed reason for the
> bad request so I can fix it?
>
> On 28 Nov 202
ption eventually ends up inside ErrorReportValve, but I’m debugging a
> remote box and don’t have any of the source code tied up - will do further
> digging.
So the reason we get a 400 Bad Request with no error detail is that we arrive
at this line with throwable set to null:
https://githu
On 28 Nov 2023, at 18:42, Christopher Schultz
wrote:
> In your debugger, when you break-on-exception, what happens if you allow the
> exception to propagate up to the first exception-handler? Does Tomcat swallow
> the exception? Or it it caught elsewhere?
The exception eventually ends up insi
Graham,
On 11/28/23 12:12, Graham Leggett wrote:
On 28 Nov 2023, at 09:41, Mark Thomas wrote:
What do I need to do to see the exception that generated the bad request, so
that I know specifically what’s wrong and can fix it?
Enabling debug logging for
org.apache.coyote.http11
On 28 Nov 2023, at 09:41, Mark Thomas wrote:
>> What do I need to do to see the exception that generated the bad request, so
>> that I know specifically what’s wrong and can fix it?
>
> Enabling debug logging for
>
> org.apache.coyote.http11.Http11Processor may help.
CVE-2023-46589 Apache Tomcat - Request Smuggling
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.0-M10
Apache Tomcat 10.1.0-M1 to 10.1.15
Apache Tomcat 9.0.0-M1 to 9.0.82
Apache Tomcat 8.5.0 to 8.5.95
Description:
Tomcat did not
On 27/11/2023 20:09, Graham Leggett wrote:
Hi all,
Long running webapps, tomcat recently updated from tomcat7 to tomcat v9.0.65.
One webapp sends a request to another.
The request fails with a 400 Bad Request, with the detail message "The server
cannot or will not process the request d
Hi all,
Long running webapps, tomcat recently updated from tomcat7 to tomcat v9.0.65.
One webapp sends a request to another.
The request fails with a 400 Bad Request, with the detail message "The server
cannot or will not process the request due to something that is perceived to be
a c
On 27/11/2023 01:49, Adwait Kumar Singh wrote:
Hmm, this gives me an impression that the Servlet APIs expect the
request/response processing to *always *happen on the container thread.
If I attempt to perform it on a non-container thread after making the
request async, I run into the risk of the
Hmm, this gives me an impression that the Servlet APIs expect the
request/response processing to *always *happen on the container thread.
If I attempt to perform it on a non-container thread after making the
request async, I run into the risk of the Request/Response objects being
recycled without
On 25/11/2023 05:30, Adwait Kumar Singh wrote:
Is there a way around this, to keep the async context open even on an error
and not close it till complete is invoked?
No. The spec requires the error handler to call complete() in onError()
and error handler doesn't, the container must.
Mark
hen I close it on the
async thread when its done.
However what I am observing is irrespective of if my not closing the
context, it's closed by default by Tomcat and the request/response objects
are recycled. Due to this during the error handling when I am trying to
read some heade
CVE-2023-45648 Apache Tomcat - Request Smuggling
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.0-M11
Apache Tomcat 10.1.0-M1 to 10.1.13
Apache Tomcat 9.0.0-M1 to 9.0.80
Apache Tomcat 8.5.0 to 8.5.93
Description:
Tomcat did not
g to be available that reports
healthiness of your own service and application, you should probably
build-to-suit.
-chris
-Original Message-
From: Christopher Schultz
Sent: Friday, September 8, 2023 3:46 PM
To: users@tomcat.apache.org
Subject: Re: Enhancement request?
Jon,
On 9/8/23 14:21,
ssage. Thank you for
your cooperation.
> -Original Message-
> From: Christopher Schultz
> Sent: Friday, September 8, 2023 3:46 PM
> To: users@tomcat.apache.org
> Subject: Re: Enhancement request?
>
> Jon,
>
> On 9/8/23 14:21, Mcalexander, Jon J. wrote:
>
Jon,
On 9/8/23 14:21, Mcalexander, Jon J. wrote:
In seeing the latest messages about the manager application, something that I and my team
would LOVE to have is just a Status app that provides all the items status wise that the
Manager app does, without any of the "Application Management" like
In seeing the latest messages about the manager application, something that I
and my team would LOVE to have is just a Status app that provides all the items
status wise that the Manager app does, without any of the "Application
Management" like restarting an app, etc. I know all the pieces are
Chris wrote...
So it looks like the backend service IS being called, but rejecting the request because
of the "UserAgent" object complaining about it.
I would log the User-Agent header from the request in your front-end before the
RequestDispatcher.forward() call, and if possible
Andy,
On 8/15/23 03:32, Andy Pont wrote:
Chris wrote…
The .forward() should keep all request headers (and many other things)
in-tact. You might want to log some things in plugins/whatever to see
what is being done.
You should be using the *same objects* your servlet got for the
request
Chris wrote…
The .forward() should keep all request headers (and many other things) in-tact.
You might want to log some things in plugins/whatever to see what is being done.
You should be using the *same objects* your servlet got for the request and response when
calling
Andy,
On 8/13/23 04:24, Andy Pont wrote:
I wrote...
Progress of sorts! The request is now returning 302 instead of 404!
Looking in the log files for the backend, it has a message that says
“Robot requests must be rejected” and the 302 response is due to a
redirect to a permission denied
I wrote...
Progress of sorts! The request is now returning 302 instead of 404!
Looking in the log files for the backend, it has a message that says “Robot
requests must be rejected” and the 302 response is due to a redirect to a
permission denied page.
My understanding was the .forward
/tomcat-8.5-doc/config/context.html
look for crossContext
- then use code something like this:
ServletContext current = request.getServletContext();
ServletContext backend = current.getContext("/backend");
RequestDispatcher rd = backend.getRequestDispatcher("/rest/abc/xx")
/config/context.html
look for crossContext
- then use code something like this:
ServletContext current = request.getServletContext();
ServletContext backend = current.getContext("/backend");
RequestDispatcher rd = backend.getRequestDispatcher("/rest/abc/xx");
rd.forward(req
rvlet which handles POST requests to
the URL: https:///plugins/abc/xx. In some cases (based on
a values in the request body), the servlet will process things itself
and generate its own response. For certain cases it just needs to
forward the request on to corresponding “backend” URL and then
tells it what to act upon.
I have started developing a new servlet which handles POST requests to
the URL: https:///plugins/abc/xx. In some cases (based on
a values in the request body), the servlet will process things itself
and generate its own response. For certain cases it just needs to
On 05/07/2023 20:15, James Boggs wrote:
Hello,
I was sent this information, I hope this meets your expectations.
Thanks. It does.
The request headers do not contain an invalid Content-Length header so
CVE-2022-42252 is not applicable to this situation.
The requests are valid HTTP requests
Hello,
I was sent this information, I hope this meets your expectations.
-
Request 1
GET / HTTP/1.1
Host: rplans.army.mil
Accept-Encoding: gzip, deflate
Accept:
text/html,application/xhtml+xml,application
Without knowing which vulnerability is being tested for and how the
vulnerability is being tested for I don't think anyone here will be able
to help.
A (cleartext) tcpdump of the associated request(s) and response(s) would
also be helpful.
Mark
On 05/07/2023 17:51, James Boggs wrote
Hi,
We have Apache Tomcat 0.0.73 installed on a Windows Server 2019 o/s which is
has a Request Smuggling vulnerability being reported in a BURP scan.
Here Tomcat documentation reports Request Smuggling has been fixed in 9.0.68,
so we don't understand why it would still be reported using 9
gt; Subject: Re: SOAP HTTP error: "HTTP/1.1 400 Bad Request" after upgrade to
> 8.5.89.
>
> On 02/06/2023 21:00, jonmcalexan...@wellsfargo.com.INVALID wrote:
> > Good afternoon,
> >
> > Have a team that just upgraded to 8.5.89 from 8.5.72 and started getting
>
] - EPMSend - Error not 200 OK. HTTP error:
"HTTP/1.1 400 Bad Request" See reply txt message in XMLPathOut directory for
g:\vdata\epmxml/001-HOU-02-20230530-0001-I-X-200-UPDATEUOW-20230601080446029.xml
[2023/06/01][17:31:01.380] : [INIT] - EPMSend (init) - EPMSend = SOAP
Is anyone awa
tomcat.apache.org
> Subject: Re: SOAP HTTP error: "HTTP/1.1 400 Bad Request" after upgrade to
> 8.5.89.
>
>
>
> On 6/2/23 14:00, jonmcalexan...@wellsfargo.com.INVALID wrote:
> > Good afternoon,
> >
> > Have a team that just upgraded to 8.5.
] - EPMSend - Error not 200 OK. HTTP error:
"HTTP/1.1 400 Bad Request" See reply txt message in XMLPathOut directory for
g:\vdata\epmxml/001-HOU-02-20230530-0001-I-X-200-UPDATEUOW-20230601080446029.xml
[2023/06/01][17:31:01.380] : [INIT] - EPMSend (init) - EPMSend = SOAP
Is anyone aware of
] - EPMSend (init) - SOAPPath =
[2023/06/01][01:05:10.012] : [INIT] - EPMSend (init) - SOAPURL =
...
[2023/06/01][17:31:01.157] : [EPMSEND] - EPMSend - Established Socket to send
EPM messages
[2023/06/01][17:31:01.227] : [EPMSEND] - EPMSend - Error not 200 OK. HTTP
error: "HTTP/1.1 400 Bad Re
rprising.
I'm wondering if the request has anything in it which specifies the
"actual" protocol which was used.
HttpServletRequest.getServletConnection().getProtocol()
(requires Servlet 6.0 / Tomcat 10.1.x onwards)
Hey, that's great.
Would it be possible to add someth
On 02/06/2023 15:31, Christopher Schultz wrote:
All,
Is it possible to get the /actual/ protocol used for communication with
a tomcat server? I'm using AJP/13 and request.getProtocol is returning
"HTTP/1.1" which is not 100% surprising.
I'm wondering if the request has
All,
Is it possible to get the /actual/ protocol used for communication with
a tomcat server? I'm using AJP/13 and request.getProtocol is returning
"HTTP/1.1" which is not 100% surprising.
I'm wondering if the request has anything in it which specifies the
"actual
Reg,
On 5/5/23 23:48, r.barc...@habmalnefrage.de wrote:
I have some questions about HTTP request smuggling in the context of Tomcat
with Apache httpd as its reverse proxy.
First of all, a few words about my current setup: At the moment I have a few
applications that are deployed this way:
I
Hello,
I have some questions about HTTP request smuggling in the context of Tomcat
with Apache httpd as its reverse proxy.
First of all, a few words about my current setup: At the moment I have a few
applications that are deployed this way:
I use Tomcat 10.1 as my backend server. It only
I am also interested in this. In my case, we added an "Abort Request" link to
the placeholder page that is displayed while the calculation is on-going, but
naturally nobody ever clicks on it. :O I am solidly In favor of anything that
fixes this.
Sam Denton (he/him)
Advisor,
On 14/03/2023 09:00, Robin Stevens wrote:
Does anybody has a pointer on how to obtain this info through official APIs, or
to some documentation related to this that I might have missed ?
The short answer is that there is no way do this via the Servlet API
that doesn't involved trying to do
Version: Tomcat 9.0.35 (embedded in Spring Boot 2.3.0.RELEASE)
Use case / problem:
The frontend is doing requests that trigger heavy calculations in the backend.
Often these requests get cancelled by the frontend before the backend has
finished doing the calculations.
The cancellation of the r
Stefan,
On 3/10/23 02:27, Stefan Mayr wrote:
Am 10.03.2023 um 07:58 schrieb Thomas Hoffmann (Speed4Trade GmbH):
You should keep an eye on this log entry: this is a GET request as your
SAMPLE POST already indicated. Maybe you can check back with your
developers that they change their code to
Am 10.03.2023 um 08:27 schrieb Stefan Mayr:
Am 10.03.2023 um 07:58 schrieb Thomas Hoffmann (Speed4Trade GmbH):
Hello,
-Ursprüngliche Nachricht-
Von: Seth Mayers
Gesendet: Freitag, 10. März 2023 01:14
An: Tomcat Users List
Betreff: Re: HTTP Error 414. The request URL is too long
Am 10.03.2023 um 07:58 schrieb Thomas Hoffmann (Speed4Trade GmbH):
Hello,
-Ursprüngliche Nachricht-
Von: Seth Mayers
Gesendet: Freitag, 10. März 2023 01:14
An: Tomcat Users List
Betreff: Re: HTTP Error 414. The request URL is too long.
Thanks. Sadly I know how the data is being
Hello,
> -Ursprüngliche Nachricht-
> Von: Seth Mayers
> Gesendet: Freitag, 10. März 2023 01:14
> An: Tomcat Users List
> Betreff: Re: HTTP Error 414. The request URL is too long.
>
> Thanks. Sadly I know how the data is being pushed. It is poorly architected.
>
ps you sort it out with the application to find what huge
> data is being push onto the url and limit it.
> > -Original Message-
> > From: Mark Thomas
> > Sent: Friday, March 10, 2023 9:34 AM
> > To: users@tomcat.apache.org
> > Subject: Re: HTTP Error 414. The
is being push onto the url and limit it.
-Original Message-
From: Mark Thomas
Sent: Friday, March 10, 2023 9:34 AM
To: users@tomcat.apache.org
Subject: Re: HTTP Error 414. The request URL is too long.
On 09/03/2023 20:59, Seth Mayers wrote:
I am running Apache Tomcat Version 9.0.48.
If I
.
-Original Message-
From: Mark Thomas
Sent: Friday, March 10, 2023 9:34 AM
To: users@tomcat.apache.org
Subject: Re: HTTP Error 414. The request URL is too long.
On 09/03/2023 20:59, Seth Mayers wrote:
> I am running Apache Tomcat Version 9.0.48.
>
> If I post a transaction tha
On 09/03/2023 20:59, Seth Mayers wrote:
I am running Apache Tomcat Version 9.0.48.
If I post a transaction that is very large, I get the "414; The request URL
is too long".
I have tried adding a bunch of parameters to my server.xml file but none of
them seem to work. I
I am running Apache Tomcat Version 9.0.48.
If I post a transaction that is very large, I get the "414; The request URL
is too long".
I have tried adding a bunch of parameters to my server.xml file but none of
them seem to work. I have tried:
maxHttpHeaderSize="262144"
Hello,
I’m currently trying to resolve an issue from our customer about a tomcat
version visible if bad characters are inserted into the URL (steps to reproduce
is to add a ‘{‘) This produces an HTTP 400 and redirects you to the default
tomcat error page with a stacktrace and version number.
To
1 - 100 of 1014 matches
Mail list logo
