Develop Reference

Quarkus - 413 Request Entity Too Large

I am developing a Quarkus application and using RESTEasy Reactive. One of the endpoints receives a multipart/form-data mime type object but when I try to use it sometimes the "413 - Request Entity too Large" error occurs.

After digging the Quarkus documentation, the property you really need to configure is this:
quarkus.http.limits.max-form-attribute-size
I have set this to 4M (4 megabytes), like this, on my application.yaml file, but of course you can configure it for any value you may want:
quarkus:
http:
limits:
max-form-attribute-size: 4M
Keep in mind that if you are using an application.properties file instead, you should do it like this:
quarkus.http.limits.max-form-attribute-size=4M

increase swagger requestTimeout

is there anyway that can help me increase the timeout of the swagger request that i issue to my RestAPI using " Try it out" of swagger ?
i roamed the internet and disn't find something usefull, and i tried to add things to my yml conf files, but i didn't know what to write
i expected to find something like this maybe :
swagger.timeout=5000
i have a spring boot application using swagger in order to test my webservices in a restController. i have a treatement that takes about 30 seconds, the thing that makes swagger throw a 500 timeout error for me.
thanks !

As far as I know, Swagger registers its endpoints as normal Spring controllers so use the underlying web container to serve its traffic.
Try to increase the global connection timeout:
server.connection-timeout=120000
Time that connectors wait for another HTTP request before closing the connection. When not set, the connector's container-specific default is used. Use a value of -1 to indicate no (that is, an infinite) timeout.

solved by adding this to ZUUL's (API Gateway)
ribbon:
ReadTimeout: 120000
ConnectTimeout: 120000

Overriding Spring Data Rest Request Mappings

We currently have a level 2 RESTful web service. We are updating the service to incorporate hypermedia support. We are using Spring Data Rest on the back-end to handle the setting of the HATEOAS properties. The problem we're having is that we still need to support our legacy API consumers until the migration can be completed, meaning we still need to support responses without HAL properties like "_links" and "_embedded".
For reasons that aren't really worth explaining, we cannot address this problem with URL versioning. We need instead to be able to map requests with an Accept header of "application/json" to our old controllers, and let SDR handle any requests with "application/hal+json". In essence, we'd like to use SDR as a fallback to handle API requests that are specifically requesting HAL-formatted responses.
I came across this excerpt in the SDR documentation:
We register a custom HandlerMapping instance that responds only to the
RepositoryRestController and only if a path is meant to be handled by
Spring Data REST. In order to keep paths that are meant to be handled
by your application separate from those handled by Spring Data REST,
this custom HandlerMapping inspects the URL path and checks to see if
a Repository has been exported under that name. If it has, it allows
the request to be handled by Spring Data REST. If there is no
Repository exported under that name, it returns null, which just means
"let other HandlerMapping instances try to service this request".
The Spring Data REST HandlerMapping is configured with
order=(Ordered.LOWEST_PRECEDENCE - 100) which means it will usually be
first in line when it comes time to map a URL path and your existing
application will never get a chance to service a request that is meant
for a Repository. For example, if you have a Repository exported under
the name "person", then all requests to your application that start
with "/person" will be handled by Spring Data REST and your
application will never see that request. If your Repository is
exported under a different name, however (like "people"), then
requests to "/people" will go to Spring Data REST and requests to
"/person" will be handled by your application.
This seems to imply that what we're trying to accomplish is possible, assuming the HandlerMapping order can be configured differently. I haven't been able to make that work so far though:
Setting SDR's HandlerMapping to Ordered.HIGHEST_PRECEDENCE seems to have no effect.
Setting SDR's HandlerMapping order to Ordered.LOWEST_PRECEDENCE seemed to disable ordering altogether, and my custom controllers did field the requests, but SDR was no longer responding to any requests. application/hal+json just resulted in a 406 status.
Is there any way to configure the HandlerMappings correctly such that my custom controllers take priority and SDR fields any requests not specifically mapped to my controllers?

Spring Boot Actuator adding X-Frame-Options = DENY to all endpoints (particularly error endpoint)

I am attempting to set the X-Frame-Options to DENY for all management endpoints, particularly the /error endpoint. I have the following in my application.properties of my Spring Boot application.
security.headers.frame=true
management.security.enabled=true
management.port=8001
When I go to http://localhost:8001/error I do not have the X-Frame-Options header, however the http://localhost:8001/trace endpoint does have the header. How do I configure my application.properties or what do I need to override to get that response header for the error endpoint?

Going through the current Spring Boot source (1.1.7.RELEASE), I don't see anyway that you can do what you want without totally doing away with the Security auto-configuration.
That is because in order for an endpoint to be eligible for the customized HTTP Headers (like X-Frame-Options) it needs to be a bean in the parent context (the one that is associated with the application on the normal port) that implements MvcEndpoint. Such beans are HealthMvcEndpoint, JolokiaMvcEndpoint etc.
My statement adove can be viewed in code at ManagementSecurityAutoConfiguration in the ManagementWebSecurityConfigurerAdapter.configure method (endpointHandlerMapping is created from the MvcEndpoint implementation beans).
The error page for the management app, is ManagementErrorEndpoint that is created in errorEndpoint of EndpointWebMvcChildContextConfiguration which is triggered when the child context is created (due the inclusion of the management app), which is too late to be included in the endpoints that supported for HTTP Headers customization

The /error endpoint is not an Actuator Endpoint and it's not secured by default (lots of errors can happen when a user is not authenticated). You could maybe make it available to anonymous users, but my guess is not even that would prevent some nasty infinite loops, where there is a mistake in the security configuration. I'm sure there's another way to add the header without Spring Security?

Remove HTTP Response headers in Java

Is there a way to remove HTTP response headers like Server and X-Powered-By?
My application is using a Weblogic server. I'm programming in Java using the Spring MVC framework and Hibernate, and using JSP for views.

Depends on where the headers are added. If inside your app, you can use a Spring MVC Interceptor to remove them after your controller calls. If outside your app, you might be able to try a Java EE filter configured in web.xml (the example is security, but the approach will also work for your use case). If its added after that, you may want to look at your web front end (Apache, IIS, what-have-you) to configure a filter there.
UPDATE
This answer describes an approach for removing specific headers, as the HttpServletResponse interface does not allow for header removal explicitly. You will need some trial and error to determine what portion of your stack is adding the header.

If you set concrete responseHeader to null it will be removed / not seen in response headers.