Working on a REST service based on Spring Boot with an embedded Tomcat I would like to limit the size of the request body for any HTTP method (POST, PUT, GET, ...).
I know of the maxPostSize property of a connector. But this property seems to limit only POST requests. Another possibility IMHO is to implement javax.servlet.Filter and to check the value of the Content-Length header.
Is there another way to achieve this that I am not aware of?
You may set the multipart.maxRequestSize property in application.properties. The default is 10Mb.
Related
While I have managed to increase the max post size on my JBoss following
http://www.mastertheboss.com/web/jboss-web-server/configuring-wildfly-upload-file-size/
now I'd like my webapp to inform users. So I would like to render on the screen that the server accepts upload up to XXX MB.
How can a webapp retrieve the max post size setting from JBoss? Is there even a container agnostic way that could work across different servlet containers?
The max-post-size allows for an expression. That means you could use a system property which could be set on the attribute and retrieved by your application.
In CLI you'd do something like this:
/system-property=max.post.size:add(value=25485760)
/subsystem=undertow/server=default-server/http-listener=default/:write-attribute(name=max-post-size,value=${max.post.size:10485760})
While the default, :10485760, is not strictly required, I'd advise it.
Then in your application you simply just to simply retrieve the system property.
So what I want to do is have different application properties for each http request that is sent to my application. I know that having profiles allows me to set up different property values for the same property. However this is only beneficial for if testing the application and switching the active profile each time. As if you have both profiles active at the same time if there is a conflicting property then one overrides the other.
In the main property that I want to include for each http request is the http header size so that I can limit the size of the header from each request. However at current I can only set this value once and have it consistent throughout the whole application.
When i call the context root of my spring-boot application "localhost:8080/api/players", which is mapped in a RestController method by the annotation #GetMapping(path= {"/",""}), undertow alway redirect (httpstatus: 307 Temporary redirect) to "localhost:8080/api/players/" adding trailing slash at the end.
My application context-root is indeed /api/players as defined in spring-boot application.properties file (server.servlet.context-path=/api/players)
I've tried with embedded-tomcat and it works correctly by setting the property server.tomcat.redirect-context-root=false
There is a way to configure undertow to act like tomcat?
Peering into the sourcecode for undertow a bit, it looks like the relevant code is here in ServletInitialHandler.java, which will issue a 307 redirect status code in the case that the request is an upgrade request... unless the request is an HTTP 2 upgrade request. This doesn't seem to be configurable by the server, although there is some attempt to avoid the redirect based on what the client does.
It's probably worthwhile to look at your HTTP requests, understand better if your HTTP client is actually making an upgrade request, and then consider either accepting this fact, or changing the client to make a different kind of request (possibly by making it send the HTTP2 upgrade request header).
I am using Spring Cloud Brixton.M3 and Spring Boot 1.3.0.RELEASE. I am sort of new in this (especially in Spring Cloud). I have created Registry Server (i.e. Eureka instance), Config server and Gateway.
As per my requirement I am intercepting each request hitting the gateway in one of my Filter to extract required information from Header and based upon that I am throwing exception or forwarding / verifying that request using Feign Client. Some time hystrix throw HystrixRuntimeException when it couldn't reach out to respective services or because of any other issues.
So What I want is:
Provide default fallback method for every forwarding request, so that I can read and process it accordingly.
Global Exception handling other than #ControllerAdvice since I am not providing any custom #HystrixCommand and Controller to call services (AOP based solution ?).
Is it possible to intercept every failed request and retry them for certain number of times ? Internally it might be happening but can I override this functionality and handle each failed request either because of TimedOutException or because of HttpConnectionPool exception ?
Update
Is it a good practice to provide own routing in Zuul gateway ? using #RestController and #HystrixCommand together ? (I think its a bad idea, because over the period of time we will end up with lots of controllers and hence actual use of intelligent routing wouldn't work as expected)
Currently there is an open issue for fallbacks with feign. There is also an open issue for fallbacks with zuul.
i am running a tomcat server which has filters (and a servlet) mapped to /xxx/*
I have client that sends //xxx/* at the HTTP header as the uri. as a result, the servlet and the filters are not getting called.
I have tried putting a filter at /* that catches the request, wraps it with a requestWrapper and override the getURI() and getServletPath() methods (they just return the URI with a single / to whoever calls)
That doesn't seem to work, so i am assuming that once tomcat receives a request it decides which servlet/filters should be evaluated against this uri BEFORE even sending it to the first filter.
Is there a way to solve this? can i make tomcat reevaluate after every filter maybe? is there another way?
thanks in advance
If the URLs in the request header are not conforming to the spec, Tomcat is doing the right thing by dropping them.
If this is the problem, you need to fix the client so that it puts proper absolute URLs into the HTTP requests.
"Hacking" Tomcat to make it accept rubbish requests is a bad idea. It will limit your options for upgrading platforms, and/or deploying in different network environments.