ffang commented on code in PR #3620: URL: https://github.com/apache/cxf/pull/3620#discussion_r4363105618
########## rt/features/logging/src/main/java/org/apache/cxf/ext/logging/event/HttpServletResponseHeaders.java: ########## @@ -0,0 +1,143 @@ +/** + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.cxf.ext.logging.event; + +import java.util.ArrayList; +import java.util.Arrays; +import java.util.Collection; +import java.util.HashMap; +import java.util.List; +import java.util.Map; +import java.util.TreeMap; +import java.util.stream.Collectors; + +import jakarta.servlet.http.HttpServletResponse; +import org.apache.cxf.common.util.PropertyUtils; +import org.apache.cxf.message.Message; +import org.apache.cxf.message.MessageUtils; + +/** + * Reads the headers that were added directly to the HttpServletResponse (by the application or by + * a servlet filter) rather than to the protocol headers of the message. Kept separate from + * DefaultLogEventMapper so that the Servlet API stays an optional dependency. + */ +final class HttpServletResponseHeaders { Review Comment: Thanks @reta , that’s a fair point. The merge logic in the logging feature duplicates the rules in `Headers.copyToResponse`, which also contributes to @coheigea ’s concerns about transport constants and formatting. I’d prefer not to add servlet headers to `PROTOCOL_HEADERS` itself. `prepare()` runs before `JAXRSOutInterceptor`, whose `prepareResponseHeaders()` copies `PROTOCOL_HEADERS` over the application’s response headers using `putAll()`. Importing servlet headers there could change precedence, including for `Content-Type`. `copyToResponse()` could also append existing `Set-Cookie` and `Link` values a second time. I’ll go ahead with the `RESPONSE_HEADERS` variant: a new key in core exposing a read-only `Map<String, List<String>>` view, evaluated lazily when logging reads it. `AbstractHTTPDestination` would provide the effective response headers at that point, accounting for servlet headers and whether protocol headers have already been copied. The logging feature would copy that view and apply sensitive-header masking, without a Servlet API dependency or transport constants. Client conduits and other transports would continue using `PROTOCOL_HEADERS` when no response-header view is provided. I’ll implement this approach so we have concrete code to review and discuss further. Thanks @reta and @coheigea ! Best Regards Freeman -- 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]
