[
https://issues.apache.org/jira/browse/CXF-6100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
member sound updated CXF-6100:
------------------------------
Description:
>From the client perspective:
LogginInInterceptor and GZIPInInterceptor in combination will log the xml
responses from webservices.
By debugging I know now that the "content-encoding" header is explicitly
removed by the GZIPInInterceptor:
// remove content encoding header as we've now dealt with it
if (key.equalsIgnoreCase("Content-Encoding")) {
protocolHeaders.remove(key);
break;
}
I think for logs quality it would be much better to leave the header as it is.
Because one could then directly see which xml responses have been reveived
compressed. And the statement "remove content encoding as we've now dealt with
it", I think when the logged xml is human readably, it should be clear to the
user that obviously the application has dealt with the encoding.
So the removal of the header does not add extra information here, but prevents
many users from clearly seeing the real xml response including all headers.
(I searched the net and came to numerous threads and users that claimed the
same issue "how can I know my received xml response was gzip compressed?", but
non of them had a solution).
It would be great if you could discuss to take out the explicit header removal
statement.
was:
>From the client perspective:
LogginInInterceptor and GZIPInInterceptor in combination will log the xml
responses from webservices.
By debugging I know now that the "content-encoding" header is explicitly
removed by the GZIPInInterceptor:
// remove content encoding header as we've now dealt with it
if (key.equalsIgnoreCase("Content-Encoding")) {
protocolHeaders.remove(key);
break;
}
I think for logs quality it would be much better to leave the header as it is.
Because one could then directly see which xml responses have been reveived
compressed. And the statement "remove content encoding as we've now dealt with
it", I think when the logged xml is human readably, it should be clear to the
user that obviously the application has dealt with the encoding.
So the removal of the header does not add extra information here, but prevents
many users from clearly seeing the real xml response including all headers.
(I searched the net and came to numerous threads and users that claimed the
same issue "how can I know my received xml response was gzip compressed?", but
non of them had a solution).
It would be great if you could discuss to take out the explicit header removal
statement.
> Include the header 'content-encoding' during logging on client side
> -------------------------------------------------------------------
>
> Key: CXF-6100
> URL: https://issues.apache.org/jira/browse/CXF-6100
> Project: CXF
> Issue Type: Improvement
> Components: Core
> Affects Versions: 3.0.2
> Reporter: member sound
> Priority: Minor
>
> From the client perspective:
> LogginInInterceptor and GZIPInInterceptor in combination will log the xml
> responses from webservices.
> By debugging I know now that the "content-encoding" header is explicitly
> removed by the GZIPInInterceptor:
> // remove content encoding header as we've now dealt with it
> if (key.equalsIgnoreCase("Content-Encoding")) {
> protocolHeaders.remove(key);
> break;
> }
> I think for logs quality it would be much better to leave the header as it
> is. Because one could then directly see which xml responses have been
> reveived compressed. And the statement "remove content encoding as we've now
> dealt with it", I think when the logged xml is human readably, it should be
> clear to the user that obviously the application has dealt with the encoding.
> So the removal of the header does not add extra information here, but
> prevents many users from clearly seeing the real xml response including all
> headers.
> (I searched the net and came to numerous threads and users that claimed the
> same issue "how can I know my received xml response was gzip compressed?",
> but non of them had a solution).
> It would be great if you could discuss to take out the explicit header
> removal statement.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
