You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using the LoggingFeature, the actual request sent should be logged by the LoggingInterceptor, even if the MultiPartFeature is used. If the headers don't already include a header MIME-Version and a header Content-Type with a boundary, they are added by the MultiPartWriter:
Notwithstanding the above, HttpUrlConnector doesn't call HeaderUtils.checkHeaderChanges(...) as other connectors. I haven't checked all others, but at least ApacheConnector, Apache5Connector and JettyConnector are calling the header checker.
I am not sure the LoggingInterceptor can be modified - it is the chicken-egg issue.
The WriterInterceptor must be invoked before the MessageBodyWriter because it can modify the HttpHeaders. So can the MessageBodyWriter modify the headers and it expects the headers already to be altered by all the Interceptors. So the WritingInterceptor cannot be invoked after the MessageBodyWriter.
As for the header check, the warning is there for the 3rd part connectors so that the modifications to headers, that are not sent to the server are noticed by the users. The ability to send the headers altered by the MBWs is there just recently, For the default HttpUrlConnector, the altered headers were always possible to send and the check was not required.
When using the
LoggingFeature
, the actual request sent should be logged by theLoggingInterceptor
, even if theMultiPartFeature
is used. If the headers don't already include a headerMIME-Version
and a headerContent-Type
with a boundary, they are added by theMultiPartWriter
:jersey/media/multipart/src/main/java/org/glassfish/jersey/media/multipart/internal/MultiPartWriter.java
Lines 122 to 136 in b0c503d
Unfortunately, the modified headers aren't logged:
This can lead to time-consuming debugging sessions, as it requires third-party tools to be used as a workaround to verify the actual requests.
It seems
LoggingInterceptor
is called to early.The text was updated successfully, but these errors were encountered: