[mrdevel2002-ui]

HttpFetcher adds the headers a request supplies to the outgoing GET as given: the httpRequestHeaders map in a per-request http-fetcher block (a FetchEmitTuple parse context on /pipes and /async, additional_fetch_config_json on tika-grpc) and the httpRequestHeaders metadata strings. httpcore's BasicLineFormatter folds CR and LF in a header value into spaces but writes the header name verbatim, so a map key such as X\r\nInjected: yes\r\n\r\nPOST /evil HTTP/1.1\r\nHost: h goes out as raw request lines. The caller gets arbitrary request lines, a body, or a second pipelined request on the fetcher's pooled keep-alive connection, which can desynchronize responses for later tuples. The docs scope per-request config to headers only, so the check belongs in the fetcher: checkHeader refuses a name that is not an RFC 7230 token and a value with CR, LF or another control character, on every path that puts a header on the request, before anything is sent.

Verified by formatting such a header through httpcore 4.4.16: the name comes out with its CRLF intact, the value with CR and LF replaced by spaces. testHeadersWithCrLfAreRefused covers a per-request name, a per-request value and the metadata string form; it fails on main (nothing thrown, the header reaches the mocked client) and passes here. ./mvnw clean install of tika-pipes-http (13 tests, checkstyle, spotless, forbidden-apis) is green.

• open issue on the Tika issue tracker: not filed yet, happy to open one or have it linked
• issue ID in the PR title and commit message: pending the issue above
• commits are squashed into a single one
• Tika builds and unit tests pass with ./mvnw clean install (affected module)
• generative AI tool used: the commit carries Generated-by: per the ASF Generative Tooling Guidance
• no conflicts with the recent main branch
• new downstream module added to tika-bom/pom.xml: not applicable