Authorization: Bearer token is logged in case of URISyntaxException and TooLongHttpHeaderException

[sameepkaranjkar]

We are experiencing following regressions after changes in issue (WARN as our root log level) :

fix #1792 change log level from debug to warn.

Current behavior : Authorization: Bearer token is printed in the logs when exception like URISyntaxException :

Expected behavior : obfuscate Authorization header content

This can be reproduced by passing some buggy characters in the URI :

curl -gv "http://localhost:8080/javascript%3a/%3c/script%3e%3cimg/onerror%3d-/%22/-/%20onmouseover%3d1/-/[%60/" -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"

2022-08-10 13:09:16.897  WARN 14184 --- [ctor-http-nio-3] r.n.http.server.HttpServerOperations     : [41cc92d6, L:/0:0:0:0:0:0:0:1:8080 - R:/0:0:0:0:0:0:0:1:2852] **Decoding failed: DefaultHttpRequest(decodeResult:** success, version: HTTP/1.1)
GET /javascript%3a/*%3c/script%3e%3cimg/onerror%3d-/%22/-/%20onmouseover%3d1/-/[%60*/ HTTP/1.1
Host: localhost:8080
User-Agent: curl/7.75.0
Accept: */*
Authorization: Bearer
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

java.net.URISyntaxException: Illegal character in path at index 96: http://localhost:8080/javascript%3a/*%3c/script%3e%3cimg/onerror%3d-/%22/-/%20onmouseover%3d1/-/[%60*/
	at java.base/java.net.URI$Parser.fail(URI.java:2913) ~[na:na]
	at java.base/java.net.URI$Parser.checkChars(URI.java:3084) ~[na:na]
	at java.base/java.net.URI$Parser.parseHierarchical(URI.java:3166) ~[na:na]
	at java.base/java.net.URI$Parser.parse(URI.java:3114) ~[na:na]
	at java.base/java.net.URI.<init>(URI.java:600) ~[na:na]
	at java.base/java.net.URI.create(URI.java:881) ~[na:na]
	at reactor.netty.http.HttpOperations.resolvePath(HttpOperations.java:389) ~[reactor-netty-http-1.0.17.jar:1.0.17]
	at reactor.netty.http.server.HttpServerOperations.<init>(HttpServerOperations.java:173) ~[reactor-netty-http-1.0.17.jar:1.0.17]
	at reactor.netty.http.server.HttpServerOperations.<init>(HttpServerOperations.java:148) ~[reactor-netty-http-1.0.17.jar:1.0.17]
	at reactor.netty.http.server.HttpTrafficHandler.channelRead(HttpTrafficHandler.java:213) ~[reactor-netty-http-1.0.17.jar:1.0.17]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:436) ~[netty-transport-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:327) ~[netty-codec-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:299) ~[netty-codec-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:251) ~[netty-transport-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) ~[netty-transport-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) ~[netty-transport-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166) ~[netty-transport-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722) ~[netty-transport-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658) ~[netty-transport-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584) ~[netty-transport-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496) ~[netty-transport-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986) ~[netty-common-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.75.Final.jar:4.1.75.Final]
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) ~[netty-common-4.1.75.Final.jar:4.1.75.Final]
	at java.base/java.lang.Thread.run(Thread.java:834) ~[na:na]

Similar behavior is also observed when TooLongHttpHeaderException is occurred.

Originally posted by @sameepkaranjkar in https://github.com/reactor/reactor-netty/pull/1793#pullrequestreview-1110175371