-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce quarkus.http.header
#21102
Conversation
quarkus.http.headers
This comment has been minimized.
This comment has been minimized.
How is this expected to behave when there is an exception? How about when then header has already been set by the application? |
The idea here is to use it for fixed headers, specially those from https://wiki.owasp.org/index.php/OWASP_Secure_Headers_Project, which must be set regardless of the outcome. Other cases should adopt a filter instead |
But is that how this behaves? Furthermore, have you tried it (and added tests) for all the various HTTP options (pure Vert.x, Reactive Routes, RESTEasy Classic and RESTEasy Reactive)? Also, the expected usage and behavior should be very clearly documented |
No, I assumed it would work since they all use vertx-http, but maybe it would be nice to have tests for them too |
I think another common use case would be to add headers for a specific URL pattern. I'll change it to a draft meanwhile |
...nsions/vertx-http/runtime/src/main/java/io/quarkus/vertx/http/runtime/VertxHttpRecorder.java
Outdated
Show resolved
Hide resolved
quarkus.http.headers
quarkus.http.header
Moving out of draft. I believe this should be enough to allow setting fixed headers in the application regardless on the requested URL. I'll check about having tests for the other HTTP options as mentioned by @geoand in #21102 (comment) (probably in a separate PR) |
httpRouteRouter.route().order(Integer.MIN_VALUE).handler(new Handler<RoutingContext>() { | ||
@Override | ||
public void handle(RoutingContext event) { | ||
event.response().headers().addAll(headers); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically the application could clear this map, which is not uncommon in the case of errors (e.g. if you are sending an error response you might clear this to make sure nothing is left over from the failed response).
I don't know how much this matters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, the primary goal of this feature is to set HTTP Headers in the response without having to write additional code. I think in the use case you described this would be still valid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least, the application can check the headers and decide if they need to be removed or not (even is most of the time, we just call clear
).
This workflow status is outdated as a new workflow run has been triggered. Failing Jobs - Building ebb18f0
Failures⚙️ Native Tests - Windows - hibernate-validator #- Failing: integration-tests/hibernate-validator
📦 integration-tests/hibernate-validator✖ |
...nsions/vertx-http/runtime/src/main/java/io/quarkus/vertx/http/runtime/HttpConfiguration.java
Outdated
Show resolved
Hide resolved
httpRouteRouter.route().order(Integer.MIN_VALUE).handler(new Handler<RoutingContext>() { | ||
@Override | ||
public void handle(RoutingContext event) { | ||
event.response().headers().addAll(headers); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least, the application can check the headers and decide if they need to be removed or not (even is most of the time, we just call clear
).
Do you guys think that we should support paths in this PR or this can be achieved in a separate PR? eg. quarkus.http.header.Pragma.value=no-cache
quarkus.http.header.Pragma.path="/foo/bar" Would apply the |
I think I'll implement support for path and method(s) in the Header configuration in this PR, this would make it more flexible IMHO |
This comment has been minimized.
This comment has been minimized.
...nsions/vertx-http/runtime/src/main/java/io/quarkus/vertx/http/runtime/VertxHttpRecorder.java
Outdated
Show resolved
Hide resolved
This allows to explicitly set fixed headers on HTTP responses Support path and method for the header Signed-off-by: George Gastaldi <[email protected]>
This workflow status is outdated as a new workflow run has been triggered. Failing Jobs - Building 5934870
Full information is available in the Build summary check run. Failures⚙️ JVM Tests - JDK 17 #- Failing: integration-tests/vault-agroal
📦 integration-tests/vault-agroal✖
✖
✖
|
Failing Jobs - Building 5934870
Failures⚙️ Native Tests - Windows - hibernate-validator #- Failing: integration-tests/hibernate-validator
📦 integration-tests/hibernate-validator✖ |
This allows to explicitly set fixed headers on HTTP responses