I build a small Spring-Boot application and have a problem with utf-8 encoded character.
In my controller I have a method like
#DeleteMapping("deleteIngredient/{ingredientId}")
public void delteIngredient(#PathVariable final String ingredientId) {
ingredientService.delteIngredient(ingredientId);
}
But calling localhost:8080/deleteIngredient/käseresults in
java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:475) ~[tomcat-embed-core-9.0.22.jar:9.0.22]
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:294) ~[tomcat-embed-core-9.0.22.jar:9.0.22]
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) [tomcat-embed-core-9.0.22.jar:9.0.22]
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:853) [tomcat-embed-core-9.0.22.jar:9.0.22]
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1587) [tomcat-embed-core-9.0.22.jar:9.0.22]
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-embed-core-9.0.22.jar:9.0.22]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_221]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_221]
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core-9.0.22.jar:9.0.22]
at java.lang.Thread.run(Thread.java:748) [na:1.8.0_221]
Any Ideas?
Spring is complaining about german Umlauts here, "ä" is not allowed.
The valid characters are defined in RFC 7230 and RFC 3986
The same reason you cannot have a domain like "dasörtliche.de".
You probably could force spring to accept Umlauts, but you would violate the RFC. My advice is to encode the links your api produces to be conform with the RFC (probably already springs default). A client then would need to encode käse to k%C3%A4se itself (if it is constructing a link itself and not using your links that are conform to RFCs), but any client should be accustomed to that already.
Related
when sending an API request to the server, the server says "Error parsing HTTP request header", although I explicitly set utf-8
request from angular:
import { Injectable } from '#angular/core';
import {HttpClient, HttpHeaders} from '#angular/common/http';
#Injectable({
providedIn: 'root'
})
export class MenuHandlerService {
constructor(private httpClient: HttpClient) {
this.fillContent('Main');
}
// tslint:disable-next-line:typedef
fillContent(category: string){
console.log(category);
this.getDataFromServer(category).
then(res => {
console.log('res: ', res);
});
}
// tslint:disable-next-line:typedef
getDataFromServer(category: string) {
const headers = new HttpHeaders({'Content-Type':'application/json; charset=utf-8'});
const url = 'https://localhost:8080/api/v1/lessons';
// #ts-ignore
return this.httpClient.get(url, headers).toPromise();
}
}
error on the java spring server
2020-11-16 18:49:43.616 INFO 11212 --- [nio-8080-exec-1] o.apache.coyote.http11.Http11Processor : Error parsing HTTP request header
Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in method name [0x160x030x010x020x000x010x000x010xfc0x030x030x8e0x1f0xbdMjM0x0dA0xe60x170xdb0xb50xf40x7f0xd50x0f0x030x9a0x06O0x80y:40xa8d*0x1f0xc20x03Z0x99]. HTTP method names must be tokens
at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:413) ~[tomcat-embed-core-9.0.38.jar:9.0.38]
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:261) ~[tomcat-embed-core-9.0.38.jar:9.0.38]
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) ~[tomcat-embed-core-9.0.38.jar:9.0.38]
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) ~[tomcat-embed-core-9.0.38.jar:9.0.38]
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1590) ~[tomcat-embed-core-9.0.38.jar:9.0.38]
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) ~[tomcat-embed-core-9.0.38.jar:9.0.38]
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) ~[na:na]
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) ~[na:na]
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) ~[tomcat-embed-core-9.0.38.jar:9.0.38]
at java.base/java.lang.Thread.run(Thread.java:832) ~[na:na]
source on git BackEnd and FrontEnd
when visiting the API through the browser the JSON object is displayed as it should be
tell me what could be the problem?
It means server does not support HTTPS, so try this:
const url = 'http://localhost:8080/api/v1/lessons';
https -> http
I'm working on a Java8 Tomcat8 Jersey2 web app and it's randomly logging a bizarre exception after successfully responding to requests. I have a filter in place for all requests to do some logging and add some values to the MDC (e.g. requestId) and the exception is coming from here. Here's the stack:
- HTTP 404 Not Found
javax.ws.rs.NotFoundException: HTTP 404 Not Found
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:323)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154)
at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at com.xyz.gatorws.webapp.LoggingFilter.doFilter(LoggingFilter.java:34)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:543)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:678)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:609)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:810)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1623)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
The odd thing is though that the request was successfully processed and a success response (200 sent back to the calling client before this stack is showing up. I'm at a loss. Also, the line in the stack coming from my code (com.xyz.gatorws.webapp.LoggingFilter.doFilter(LoggingFilter.java:34)) is the following:
chain.doFilter(httpRequest, response);
This is bizarre given that the filter runs before the request is processed. Argh! I must be missing something. I clear the logging context in the LoggingFilter.destroy() method so I can't see that another request is involved, but I'm really at a loss.
Any thoughts would be much appreciated.
In case this can help the asker or others
My configuration was Java9 Tomcat9 Jersey2. I got a problem like this one cause the matched method wasn't annotated with any HTTP method annotation. In my case the #GET was missing. The method was returning a Response object and after the last statement before the return Response ... it was throwing NotFoundException. I think Jersey thought this method was a subresource locator that was found due to the #Path annotation.
So i changed from this:
#Path("unique/page")
#Consumes("*/*")
#RolesAllowed("owner")
public Response getUnique(#PathParam("userUUID") String userUUID) throws RuntimeException {
LogNdc.log("userUUID: " + userUUID);
SearchCompanieService scs = new SearchCompanieService();
CompanyPagePojo cpp = scs.searchByFieldNameAutoCommit("userPojoOwnerId", userUUID);
System.out.println(cpp);
return Response.status(Status.OK).entity(cpp).build();
}
To this:
#Path("unique/page")
#GET
#Consumes("*/*")
#RolesAllowed("owner")
public Response getUnique(#PathParam("userUUID") String userUUID) throws RuntimeException {
LogNdc.log("userUUID: " + userUUID);
SearchCompanieService scs = new SearchCompanieService();
CompanyPagePojo cpp = scs.searchByFieldNameAutoCommit("userPojoOwnerId", userUUID);
System.out.println(cpp);
return Response.status(Status.OK).entity(cpp).build();
}
But in my case the request was not generating any 200 response code due to the exception, the client was getting 500 because I had a RuntimeExceptionMapper.
On our production (tomcat, java8) servers, from time to time, we're seeing the following stacktrace in the logfiles:
java.lang.Exception
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:142)
at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:102)
at org.springframework.web.method.annotation.ModelAttributeMethodProcessor.createAttribute(ModelAttributeMethodProcessor.java:139)
at org.springframework.web.servlet.mvc.method.annotation.ServletModelAttributeMethodProcessor.createAttribute(ServletModelAttributeMethodProcessor.java:82)
at org.springframework.web.method.annotation.ModelAttributeMethodProcessor.resolveArgument(ModelAttributeMethodProcessor.java:106)
at org.springframework.web.method.support.HandlerMethodArgumentResolverComposite.resolveArgument(HandlerMethodArgumentResolverComposite.java:121)
at org.springframework.web.method.support.InvocableHandlerMethod.getMethodArgumentValues(InvocableHandlerMethod.java:158)
at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:128)
at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:97)
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:827)
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:738)
at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:967)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:901)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:861)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:635)
at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:728)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:591)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:527)
at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:380)
at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:323)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:166)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:660)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:798)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
What could be the cause of this exception and how can I trace the origin?
Thanks
Based on e.g.: Spring Boot custom error controller is showing the incorrect exception this
might be an Exception thrown from your own code, so maybe search your own codebase for places where Exception is thrown.
To complicate matters a bit this is all implemented in native code, see: class newInstance propagates checked and unchecked exceptions - is it true?
But maybe it is further obfuscated because the original exception on your production system has already been generated many times (since startup) and has been converted to extremely optimized native code.
In that case you can:
see this in the logging when the application just is started; or
if you start Java with this extra parameter: -XX:-OmitStackTraceInFastThrow (before your applications jar/Main class name and application arguments)
I hope that helps, I'm curious if this is the case, so please let me (and all other readers that might come here later know).
I don’t have spring mvc code in front of me right now, but it looks like there is a faulty end point.
ModelAttributeMethodProcessor tries to create a model attribute (that should be basically something in your code, and this class should have constructor) and fails to instantiate it.
It’s possible that calls like this will respond with 500 http status (or at least not 200). Now, probably you have an access log (log with all the requests / response statuses) somewhere - it can be a gateway, an applicative load balancer, ELB maybe, it really depends where you’re running.
In this case you might be able to examine these logs and try to find the endpoints that sometimes return 5XX codes. Maybe there will be the same endpoint that sometimes doesn’t work. Now as you say, it shouldn’t really cause an issue to your server, but the client who expects to get the result by calling this endpoint obviously doesn’t get the desired response.
I'm facing some problems with my project (probably because windows, antivirus or both).
What's happening is the following error:
SEVERE: Exception Processing ErrorPage[errorCode=404, location=/404.jsp]
org.apache.jasper.JasperException: org.apache.jasper.JasperException: Unable to compile class for JSP
at org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:565)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:389)
at org.apache.jasper.servlet.JspServlet._serviceJspFile(JspServlet.java:386)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:40001)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:728)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:472)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:395)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:316)
at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:395)
at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:254)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:177)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:800)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:800)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1471)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.jasper.JasperException: Unable to compile class for JSP
at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:610)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:368)
... 26 more
Caused by: java.io.IOException: classFile.delete() failed
at org.apache.jasper.compiler.SmapUtil$SDEInstaller.install(SmapUtil.java:204)
at org.apache.jasper.compiler.SmapUtil.installSmap(SmapUtil.java:166)
at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:510)
at org.apache.jasper.compiler.Compiler.__compile(Compiler.java:379)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:41002)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:351)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:335)
at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:595)
... 27 more
Looks like the file that classFile.delete() is trying to delete is in use.
We cannot add a exception in the antivirus....
I found a post from 2006 that says "My workaround was to modify the SmapUtil class. If the rename fails on the first try, it waits 50ms then retries (loops as needed). So far it always works on the second try after the 50ms delay."
My question is, where that SmapUtil class is located and how to edit that delete (and rename) methods?
I can't find this info anywhere
Thanks
Ensure you have Tomcat and Jasper configured for running in production.
To solve your specific issue you could set the Jasper option suppressSmap to true or precompile your JSP files, or both.
SMAP provides JSR-045 support for Jasper; It creates mappings from the generated bytecode back to the source JSP files to aid in debugging.
See this page for information on Jasper configuration.
I was able to "fix" it by changing that Tomcat method (delete and rename)
Looks like that whichever file it was trying to delete/rename, was being user by another process (likely antivirus)
So I cloned the source-code from Tomcat's Github, changed the class and voilá, it's working now.
That method was something like:
if ( !classPath.delete(..) )
throw Exception...
then I changed for something like:
while ( !classPath.delete(..) && count < 10){
Thread.wait(50);
count++
}
if (count == 10)
Throw Exception
There are characters [ and ] in my request URL, and project deployed on Tomcat8.5.33. Some exception happens when I post request.
20-Sep-2018 10:55:36.494 WARNING [http-nio-8075-exec-2] org.apache.tomcat.util.http.parser.HttpParser.<clinit> Character [[] is not allowed and will continue to be rejected.
20-Sep-2018 10:55:36.494 WARNING [http-nio-8075-exec-2] org.apache.tomcat.util.http.parser.HttpParser.<clinit> Character []] is not allowed and will continue to be rejected.
20-Sep-2018 10:56:07.083 INFO [http-nio-8075-exec-10] org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request header
Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:479)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:684)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
Tomcat8.5.33 doesn't allow special character in URL, like |{}[].
And there are two methods to avoid this error.
If your special character is one of |{}, you could add config conf\catalina.properties like below directly:
tomcat.util.http.parser.HttpParser.requestTargetAllow=|{}
If your special character are some others, you could config conf\server.xml like below:
<Connector port="8075" protocol="HTTP/1.1" relaxedQueryChars='|[]'
connectionTimeout="20000"
redirectPort="8443" />
There are characters [ and ] in my request URL ....
This is the real problem. You are sending your server a request with an invalid URL. A valid URL cannot contain [ and ] ... except in an IP literal in the host part. They must be %-escaped in all other cases.
The correct solution is to fix your URLs and/or the software that generates them on the client side.
Tomcat is simply enforcing the rules in the URL / URI specifications ... that have been in the spec for the last 20+ years or so.
Reference:
RFC3986 - Uniform Resource Identifier (URI): Generic Syntax