logback LOGBACK-1229: fix tomcat byte send for chunked encoding

ability to log byteCount when transfer-encoding is chunked. until now logback-acces was reporting - instead of the actual byte count. The logic is copied from ByteSentElement class from tomcat's access logs implementation

Dec 05 '16 17:12 ckoutsouridis

Is there a Jira issue for this PR? If not, can you please create one?

Dec 05 '16 19:12 ceki

Created ticket and updated the title as well

Dec 05 '16 20:12 ckoutsouridis

Do you know under what conditions the "if (length <= 0)" branch would be active?

Dec 05 '16 20:12 ceki

response.getBytesWritten(false); returns 0 when no bytes are written, like in a regular 304 response status. I had to add that last check so that when no bytes are written, the method returns -1 in order for the converter (ContentLengthConverter.java) to properly set it to -. I noticed that if the method returns 0, the 0 is written in the logs instead of the dash. This covers the =0 part. For the < part, i am not really sure if it's possible to ever happen, but since the same check was in Tomcat's access log's implementation, i kept it as it was

Dec 06 '16 08:12 ckoutsouridis

Unless we can explain the "request.getAttribute( Globals.SENDFILE_FILE_START/END_ATTR)" part, we should not keep it.

Dec 06 '16 10:12 ceki

those attributes are used by tomcat's DefaultServlet when

serving static resources
send file is enabled (default is enabled)
file content is more that the configured one (default about 50kb i think)

The response headers in such a case will look like:

Accept-Ranges:bytes
Content-Length:10140000
Date:Tue, 06 Dec 2016 12:12:53 GMT

i believe we could do a workaround when getBytesWritten() returns <=0 to fallback to response.getContentLenght() which is populated as well in the above case.

Or to keep the change minimal we could first check response.getContentLenght() and then fallback to: getBytesWritten()

Dec 06 '16 12:12 ckoutsouridis