[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #28 from Mark Thomas --- Tomcat 7.0.x also behaves correctly. Since there is nothing to fix here, I am closing this as WORKSFORME. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 --- Comment #27 from Mark Thomas --- The current 8.0.x code also does not emit the final chunk. This behaviour is correct. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 --- Comment #26 from Mark Thomas --- This is what I was thinking of from 2014 http://markmail.org/thread/znillhttbmvsl5e5 and the change to close the connection without the final chunk was back-ported to 8.0.x and 7.0.x. Thanks makes me more in favour of fixing this. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 --- Comment #25 from Mark Thomas --- I'm leaning towards fixing it but... I do recall we had a discussion around this topic or one similar in the past. Let me see if I can find a reference to it. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 --- Comment #24 from Christopher Schultz --- It sounds like this should really be WONTFIX: Tomcat 7.0.x and 8.0.x will emit a 0-byte final chunk, and changing that in the 7.0.x or 8.0.x branches should probably not be done. 8.5.x and 9.0.x represent new (and compliant) behavior and require no change. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 --- Comment #23 from Mark Thomas --- As does 8.5.x -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 --- Comment #22 from Mark Thomas --- 9.0.x behaves as expected and closes the connection without a final chunk. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 Chuck Caldarale changed: What|Removed |Added Version|7.0.0 |7.0.70 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 sharan changed: What|Removed |Added Version|7.0.70 |7.0.0 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 --- Comment #21 from Christopher Schultz --- (In reply to Konstantin Kolinko from comment #20) > the correct behaviour after an OOM like that is to abort the connection, > without any terminating chunk. Okay, then Tomcat 8 is non-compliant. > OOM = the processing failed, the client should note that the failure > occurred, e.g. that the document that the person downloads is truncated. > > Sending the terminating 0-length chunk gives an illusion that everything is > OK, while it certainly is not. > > > See r1602443 and CLOSE_NOW action that I mentioned in Comment 9. > > Discussion that lead to that change is in thread > titled "Error handling" on dev@, started 2014-05-29. > http://tomcat.markmail.org/thread/znillhttbmvsl5e5 If the desired behavior is to close the connection without a terminating 0-byte chunk (which is reasonable behavior IMO), then I think Tomcat should be consistent across versions. But I have now published a simple reproducible test case that can be used across Tomcat versions to verify the behavior claimed in this bug, so that should make it easier to test should a decision be made either way. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 --- Comment #20 from Konstantin Kolinko --- (In reply to Christopher Schultz from comment #19) > Tomcat 7.0.76 chokes on this JSP in the way that qixiaobo...@gmail.com has > described. Here are the TCP responses from Tomcat 7 captured using Wireshark: Christopher, the correct behaviour after an OOM like that is to abort the connection, without any terminating chunk. OOM = the processing failed, the client should note that the failure occurred, e.g. that the document that the person downloads is truncated. Sending the terminating 0-length chunk gives an illusion that everything is OK, while it certainly is not. See r1602443 and CLOSE_NOW action that I mentioned in Comment 9. Discussion that lead to that change is in thread titled "Error handling" on dev@, started 2014-05-29. http://tomcat.markmail.org/thread/znillhttbmvsl5e5 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 Christopher Schultz changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #19 from Christopher Schultz --- Tomcat 7.0.76 chokes on this JSP in the way that qixiaobo...@gmail.com has described. Here are the TCP responses from Tomcat 7 captured using Wireshark: Packet 1: 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d HTTP/1.1 200 OK. 0010 0a 53 65 72 76 65 72 3a 20 41 70 61 63 68 65 2d .Server: Apache- 0020 43 6f 79 6f 74 65 2f 31 2e 31 0d 0a 53 65 74 2d Coyote/1.1..Set- 0030 43 6f 6f 6b 69 65 3a 20 4a 53 45 53 53 49 4f 4e Cookie: JSESSION 0040 49 44 3d 41 32 31 46 37 43 44 39 30 33 42 45 30 ID=A21F7CD903BE0 0050 38 45 32 43 33 35 31 45 33 36 44 46 39 37 33 41 8E2C351E36DF973A 0060 45 45 43 3b 20 50 61 74 68 3d 2f 65 78 61 6d 70 EEC; Path=/examp 0070 6c 65 73 3b 20 48 74 74 70 4f 6e 6c 79 0d 0a 43 les; HttpOnly..C 0080 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 ontent-Type: tex 0090 74 2f 68 74 6d 6c 3b 63 68 61 72 73 65 74 3d 49 t/html;charset=I 00a0 53 4f 2d 38 38 35 39 2d 31 0d 0a 54 72 61 6e 73 SO-8859-1..Trans 00b0 66 65 72 2d 45 6e 63 6f 64 69 6e 67 3a 20 63 68 fer-Encoding: ch 00c0 75 6e 6b 65 64 0d 0a 44 61 74 65 3a 20 46 72 69 unked..Date: Fri 00d0 2c 20 31 37 20 4d 61 72 20 32 30 31 37 20 31 34 , 17 Mar 2017 14 00e0 3a 33 35 3a 35 32 20 47 4d 54 0d 0a 0d 0a 32 30 :35:52 GMT20 00f0 0d 0a 54 68 65 20 66 69 72 73 74 20 63 68 75 6e ..The first chun 0100 6b 20 73 68 6f 75 6c 64 20 62 65 20 68 65 72 65 k should be here 0110 2e 0a 0d 0a Packet 2: 32 32 0d 0a 0a 54 68 65 20 73 65 63 6f 6e 64 20 22...The second 0010 63 68 75 6e 6b 20 73 68 6f 75 6c 64 20 62 65 20 chunk should be 0020 68 65 72 65 2e 0a 0d 0a here The only data exchange after Packet 2 above are TCP control packets... no actual data. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 --- Comment #18 from Christopher Schultz --- The following JSP runs (somewhat) correctly on Tomcat 8.0.41. It emits 2 chunks, then intentionally causes an OOME before the third section of the response. Tomcat captures the error and emits a 0-length chunk to properly end the response. === CUT === The first chunk should be here. <% out.flush(); %> The second chunk should be here. <% out.flush(); // Let's cause an OOME int[] a = new int[Integer.MAX_VALUE]; %> The final chunk should be here. === CUT === -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 Mark Thomas changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #17 from Mark Thomas --- A reproducible test case is required for this issue. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 qixiaobo...@gmail.com changed: What|Removed |Added Status|NEEDINFO|NEW -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 --- Comment #16 from qixiaobo...@gmail.com --- (In reply to Ty from comment #14) > > OOMEs can happen for a number of reasons -- not always complete > > heap-exhaustion. > > Very true, I forgot about the "initialize an object array of > size=Integer.MAX_VALUE" operations that OOME before they even begin. > > > I'd be interested to see if JMX reports an increase in the OOME count when > > these > > zero-length chunks are dropped from the responses. > > Once the heap size was increased, I see a very sharp and short-lived (i.e. > garbage-collectable) increase in OldGen utilization. From memory, a spike > of about 850MB. I think that's what you're asking about. > > Besides the probably-swallowed OOME, that just leaves the mystery of a > response that (when under memory constraints) is missing the last chunk but > otherwise is complete. I'd wager a third-party library is to blame -- in > our case and in OP's case, there is a JSON library in the mix-- but what is > strange to me is the response isn't compliant with the RFC spec for > Transfer-Encoding: chunked, at least according to my reading of it: a > response can't be considered complete without the zero byte chunk, but the > server seems to think it is. No oom -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
Informo que alterei meu email para dea.san...@infobase.com.br Dea Pacheco Obrigado - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 --- Comment #15 from qixiaobo...@gmail.com --- Sorry for my late response. This request will logout my application. I think there is something wrong with shiro framework. in localhost.2017-02-23.log: org.apache.shiro.UnavailableSecurityManagerException: No SecurityManager accessible to the calling code, either bound to the org.apache.shiro.util.ThreadContext or as a vm static singleton. This is an invalid application configuration. at org.apache.shiro.SecurityUtils.getSecurityManager(SecurityUtils.java:123) at org.apache.shiro.subject.Subject$Builder.(Subject.java:626) at org.apache.shiro.SecurityUtils.getSubject(SecurityUtils.java:56) at org.apache.shiro.web.tags.SecureTag.getSubject(SecureTag.java:43) at org.apache.shiro.web.tags.PermissionTag.isPermitted(PermissionTag.java:66) at org.apache.shiro.web.tags.HasPermissionTag.showTagBody(HasPermissionTag.java:32) at org.apache.shiro.web.tags.PermissionTag.onDoStartTag(PermissionTag.java:57) at org.apache.shiro.web.tags.SecureTag.doStartTag(SecureTag.java:53) at org.apache.jsp.page.common.head_jsp._jspService(head_jsp.java:215) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:731) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:439) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339) at javax.servlet.http.HttpServlet.service(HttpServlet.java:731) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:747) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:603) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:542) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:955) at org.apache.jsp.page.error._404_jsp._jspService(_404_jsp.java:103) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:731) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:439) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339) at javax.servlet.http.HttpServlet.service(HttpServlet.java:731) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:747) Since I remove some configs , I can receive the 0-sized trunk package and it becomes normal. Maybe in this case it's a fatal error ? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 --- Comment #14 from Ty --- > OOMEs can happen for a number of reasons -- not always complete > heap-exhaustion. Very true, I forgot about the "initialize an object array of size=Integer.MAX_VALUE" operations that OOME before they even begin. > I'd be interested to see if JMX reports an increase in the OOME count when > these > zero-length chunks are dropped from the responses. Once the heap size was increased, I see a very sharp and short-lived (i.e. garbage-collectable) increase in OldGen utilization. From memory, a spike of about 850MB. I think that's what you're asking about. Besides the probably-swallowed OOME, that just leaves the mystery of a response that (when under memory constraints) is missing the last chunk but otherwise is complete. I'd wager a third-party library is to blame -- in our case and in OP's case, there is a JSON library in the mix-- but what is strange to me is the response isn't compliant with the RFC spec for Transfer-Encoding: chunked, at least according to my reading of it: a response can't be considered complete without the zero byte chunk, but the server seems to think it is. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 --- Comment #13 from Christopher Schultz --- (In reply to Ty from comment #12) > - there is no OOME in stdout or stderr I seem to recall some try/catch code in certain places in Tomcat that swallowed exceptions that I thought ought to at least be logged. It's possible that this particular edge-case hits those catches. OOMEs can happen for a number of reasons -- not always complete heap-exhaustion. So you might not be able to tell an OOME occurred if it didn't get logged to stderr and you were just watching e.g. total JVM memory usage. I'd be interested to see if JMX reports an increase in the OOME count when these zero-length chunks are dropped from the responses. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 --- Comment #12 from Ty --- qixiaobo.nj, please try increasing your max heap. We ran into this exact situation last week. The entire response is delivered to the browser, except that one crucial part (the zero-byte chunk signalling the end of the data stream). Like qixiaobo.nj, we were seeing it in some environments but not others. Gradually we merged configs from those environments and found that increasing the heap max (in our case, more than doubling it) resolved the issue. The behavior was unusual in many ways: - again, the entire data stream was delivered to the browser, just not that "0". - the server seems to *think* it sent a complete response (it logged the response summary to the access log) - there is no OOME in stdout or stderr - there is no tell-tale sign of memory trouble, or even an increase in memory utilization in JMX+JConsole - in our case, the data stream size (about 700K) was several orders of magnitude smaller than the max heap (768m). Unfortunately I don't have any better info than qixiaobo.nj as to how this can be reproduced. The application we were dealing with is heavily dependent on third-party libraries and I don't have any evidence where the problem lies. I figured I'd leave this here for qixiaobo.nj or anyone else who runs across this. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 Mark Thomas changed: What|Removed |Added Status|REOPENED|NEEDINFO --- Comment #11 from Mark Thomas --- This needs a simple test case (without the 3rd party libraries) to demonstrate the issue. Without such a test case, the assumption is going to be that it is not a Tomcat bug. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 --- Comment #10 from Christopher Schultz --- (In reply to qixiaobo.nj from comment #5) > Very simple code! > > OutputStream out = outputMessage.getBody(); What type is the "outputMessage" reference? You need to post more code. The stack traces are confusing to me. Is that a thread dump? A show of a deadlock situation? What are you trying to show? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 --- Comment #9 from Konstantin Kolinko --- > Server number: 7.0.70.0 You are using Tomcat 7.0.70. The current version of Tomcat 7 is 7.0.75. I wonder whether the behaviour is reproducible with Tomcat 7.0.75. > org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:318) The above class in stacktrace means that you are using BIO connector implementation. > Comment 5 >OutputStream out = outputMessage.getBody(); >String text = JSON.toJSONString(obj, features); >byte[] bytes = text.getBytes(charset); >out.write(bytes); Can this be simplified further to be reproduced without 3-rd party classes? A simple sample web application? It seems that your hypothesis in Comment 6 and Comment 7 is the following: 1. The zero-length chunk is not send because org.apache.coyote.http11.filters.ChunkedOutputFilter.end() method is not called. 2. The end() method is not called (in org.apache.coyote.http11.AbstractOutputBuffer.endRequest()) because 'AbstractOutputBuffer.finished' flag is 'true'. 3. The 'AbstractOutputBuffer.finished' flag is set to 'true' in org.apache.coyote.http11.AbstractHttp11Processor.action() when processing 'case CLOSE_NOW'. This behaviour is by design. The "CLOSE_NOW" action code means that connection must be terminated immediately, without any further I/O. E.g. some fatal error has occurred. E.g. the client went away (closed its side of connection) without waiting for your end chunk. See the javadoc: https://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/coyote/ActionCode.java?revision=1740727&view=markup#l34 The CLOSE_NOW code was introduced by r1602443 (Tomcat 7.0.55 onwards), 2,5 years ago. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is missing the last zero-length chunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750 Konstantin Kolinko changed: What|Removed |Added Summary|still content-length header |A response that uses |with chunked|Transfer-Encoding: chunked ||is missing the last ||zero-length chunk --- Comment #8 from Konstantin Kolinko --- Updated the SUMMARY field. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
