reta commented on a change in pull request #812:
URL: https://github.com/apache/cxf/pull/812#discussion_r659111340
##########
File path:
rt/rs/sse/src/main/java/org/apache/cxf/jaxrs/sse/interceptor/SseInterceptor.java
##########
@@ -73,16 +73,6 @@ public void handleMessage(Message message) {
servletResponse = (HttpServletResponse)response;
builder = Response.status(servletResponse.getStatus());
- @SuppressWarnings("unchecked")
Review comment:
Thanks a lot for explanation @timothyjward, I suspect `Content-Length`
could be an issue in this case, I will take a look shortly as well to confirm
that. Have you seen the examples of `Upgrade` headers to be sent as well in
response since you mentioned it? (would appreciate the pointers).
> There are then plenty of headers which only make sense on a request, and
should not be used in a response. The Host and User-Agent headers that you
reference are examples of this sort of header, others would include Cookie,
Authorization and Accept. Adding the request headers to an HTTP response is
confusing as they aren't supposed to be there and don't fit the expected
semantics.
I would argue that there is no harm of sending `User-Agent` or `Host` back
in the response, moreover there is absolutely nothing preventing users from
sending any headers in the response (obviously, CXF does not send Cookie & co
back). But I think this is subject of another discussion. Back to your
question:
> I suppose my question would be, what is the reason?
Right now PROTOCOL_HEADERS are used in many places (primarily, interceptors)
to propagate headers down to the response level, they are flushed by last
interceptor in the chain (like `SseInterceptor` in this case). You could look
in the codebase for example, I would be happy to provide direct pointers if you
are curious.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
