You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2017/02/20 13:39:53 UTC
[Bug 60750] New: still content-length header with chunked
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
Bug ID: 60750
Summary: still content-length header with chunked
Product: Tomcat 7
Version: 7.0.70
Hardware: PC
OS: Linux
Status: NEW
Severity: major
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: qixiaobo.nj@gmail.com
Target Milestone: ---
Created attachment 34768
--> https://bz.apache.org/bugzilla/attachment.cgi?id=34768&action=edit
chunked with content-length
POST http://192.168.1.153:8080/kzf6/user/resetMyPassword.json HTTP/1.1
Host: 192.168.1.153:8080
Connection: keep-alive
Content-Length: 15
Accept: application/json, text/javascript, */*; q=0.01
Origin: http://192.168.1.153:8080
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/56.0.2924.87 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
DNT: 1
Referer: http://192.168.1.153:8080/kzf6/page/index/index.jsp
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6,ja;q=0.4,zh-TW;q=0.2
Cookie: JSESSIONID=58A5A067D9686D43146177A27F7C3ADA; __lnkrntdmcvrd=-1;
currMenu=%E9%A6%96%E9%A1%B5;
PLAY_SESSION="2c9de2e98e99047a6f56d82c3558b38ba77efb9e-accountName=&stationCode=CHS201604060327&appId=wxee37461196767726&flag=&accountId=586&wxAppName=F6%E9%AB%98%E5%AE%9D%E6%B1%BD%E8%BD%A6%E6%9C%8D%E5%8A%A1%E5%8F%B7&activeDate=null&stationId=537&account=gbxq&parentAccountId=null&password=96e79218965eb72c92a549dd5a330112&isSystem=1";
F6ONL_SESSION="d4b1bcc15c082a61a1e12db295e3c51f3635de20-pwd=96e79218965eb72c92a549dd5a330112&username=gbxq&creditValue=0.0&orgCode=CHS201604060327&prjRights=bsx2016%2Cpts2016&userid=243515852076984501487578195330";
totalReminder=%5Bobject%20Object%5D
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Date: Mon, 20 Feb 2017 08:12:05 GMT
e2
{"btnStatus":"","idBill":null,"idCar":null,"idCustomer":null,"idPay":null,"idStock":null,"list":null,"noBill":null,"noPay":null,"noStock":null,"options":null,"pageResult":null,"param":"","status":"success","str":"","token":""}
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #15 from qixiaobo.nj@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.<init>(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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #20 from Konstantin Kolinko <kn...@gmail.com> ---
(In reply to Christopher Schultz from comment #19)
> Tomcat 7.0.76 chokes on this JSP in the way that qixiaobo.nj@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #26 from Mark Thomas <ma...@apache.org> ---
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #9 from Konstantin Kolinko <kn...@gmail.com> ---
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #13 from Christopher Schultz <ch...@christopherschultz.net> ---
(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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] still content-length header with chunked
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #5 from qixiaobo.nj@gmail.com ---
Very simple code!
OutputStream out = outputMessage.getBody();
String text = JSON.toJSONString(obj, features);
byte[] bytes = text.getBytes(charset);
out.write(bytes);
The same code runs in product or development env very normal .Just become
abnormal in test env (with ip).
信息: Server version: Apache Tomcat/7.0.70
信息: Server built: Jun 15 2016 16:27:45 UTC
信息: Server number: 7.0.70.0
信息: OS Name: Linux
信息: OS Version: 2.6.32-504.el6.x86_64
信息: Architecture: amd64
信息: Java Home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65.x86_64/jre
信息: JVM Version: 1.7.0_65-mockbuild_2014_07_16_06_06-b00
信息: JVM Vendor: Oracle Corporation
信息: CATALINA_BASE: /home/opt/apache-tomcat-7.0.70-erp
信息: CATALINA_HOME: /home/opt/apache-tomcat-7.0.70-erp
信息: Command line argument:
-Djava.util.logging.config.file=/home/opt/apache-tomcat-7.0.70-erp/conf/logging.properties
信息: Command line argument:
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
信息: Command line argument: -Djdk.tls.ephemeralDHKeySize=2048
信息: Command line argument: -Dcom.sun.management.jmxremote
信息: Command line argument: -XX:PermSize=64M
信息: Command line argument: -XX:MaxNewSize=128m
信息: Command line argument: -XX:MaxPermSize=128m
信息: Command line argument: -Djava.rmi.server.hostname=192.168.1.153
信息: Command line argument: -Dcom.sun.management.jmxremote.port=9999
信息: Command line argument: -Dcom.sun.management.jmxremote.ssl=false
信息: Command line argument: -Dcom.sun.management.jmxremote.authenticate=false
信息: Command line argument: -XX:+PrintGCTimeStamps
信息: Command line argument: -XX:+PrintGCDetails
信息: Command line argument: -Xloggc:logs/gc.log
信息: Command line argument: -Xdebug
信息: Command line argument: -Xnoagent
信息: Command line argument: -Djava.compiler=NONE
信息: Command line argument:
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5888
信息: Command line argument:
-Djava.endorsed.dirs=/home/opt/apache-tomcat-7.0.70-erp/endorsed
信息: Command line argument: -Dcatalina.base=/home/opt/apache-tomcat-7.0.70-erp
信息: Command line argument: -Dcatalina.home=/home/opt/apache-tomcat-7.0.70-erp
信息: Command line argument:
-Djava.io.tmpdir=/home/opt/apache-tomcat-7.0.70-erp/temp
信息: The APR based Apache Tomcat Native library which allows optimal performance
in production environments was not found on the java.library.path:
/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
sharan <sh...@gmail.com> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #27 from Mark Thomas <ma...@apache.org> ---
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
qixiaobo.nj@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] still content-length header with chunked
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #2 from qixiaobo.nj@gmail.com ---
Created attachment 34771
--> https://bz.apache.org/bugzilla/attachment.cgi?id=34771&action=edit
normal request
with 0-sized chunk
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #10 from Christopher Schultz <ch...@christopherschultz.net> ---
(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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #23 from Mark Thomas <ma...@apache.org> ---
As does 8.5.x
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #12 from Ty <ty...@gmail.com> ---
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |WORKSFORME
--- Comment #28 from Mark Thomas <ma...@apache.org> ---
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #25 from Mark Thomas <ma...@apache.org> ---
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #18 from Christopher Schultz <ch...@christopherschultz.net> ---
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] still content-length header with chunked
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
qixiaobo.nj@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |---
--- Comment #7 from qixiaobo.nj@gmail.com ---
"http-bio-8080-exec-15@10822" daemon prio=5 tid=0x1dd nid=NA runnable
java.lang.Thread.State: RUNNABLE
at org.apache.coyote.Response.setCommitted(Response.java:217)
at
org.apache.coyote.http11.InternalOutputBuffer.commit(InternalOutputBuffer.java:194)
at
org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:776)
at org.apache.coyote.Response.action(Response.java:174)
at org.apache.coyote.Response.sendHeaders(Response.java:348)
at
org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:352)
at
org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:334)
at
org.apache.catalina.connector.CoyoteOutputStream.flush(CoyoteOutputStream.java:101)
at
org.springframework.http.converter.AbstractHttpMessageConverter.write(AbstractHttpMessageConverter.java:180)
at
org.springframework.web.servlet.mvc.method.annotation.AbstractMessageConverterMethodProcessor.writeWithMessageConverters(AbstractMessageConverterMethodProcessor.java:148)
at
org.springframework.web.servlet.mvc.method.annotation.AbstractMessageConverterMethodProcessor.writeWithMessageConverters(AbstractMessageConverterMethodProcessor.java:90)
at
org.springframework.web.servlet.mvc.method.annotation.RequestResponseBodyMethodProcessor.handleReturnValue(RequestResponseBodyMethodProcessor.java:189)
at
org.springframework.web.method.support.HandlerMethodReturnValueHandlerComposite.handleReturnValue(HandlerMethodReturnValueHandlerComposite.java:69)
at
org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:122)
at
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandleMethod(RequestMappingHandlerAdapter.java:745)
at
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:686)
at
org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:80)
at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:925)
at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:856)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:953)
at
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:855)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:650)
at
org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:829)
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.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at
org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
at
org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
at
org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
at
org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at
org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
at
org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
at
org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
at
org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at
org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at
org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:387)
at
org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
at
org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:343)
at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:260)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:218)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:442)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1082)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:623)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:318)
- locked <0x2bf4> (a org.apache.tomcat.util.net.SocketWrapper)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
Then
"http-bio-8080-exec-15@10822" daemon prio=5 tid=0x1dd nid=NA runnable
java.lang.Thread.State: RUNNABLE
at
org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:905)
at org.apache.coyote.Response.action(Response.java:172)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:442)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1082)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:623)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:318)
public void endRequest()
throws IOException {
if (!committed) {
// Send the connector a request for commit. The connector should
// then validate the headers, send them (using sendHeader) and
// set the filters accordingly.
response.action(ActionCode.COMMIT, null);
}
if (finished)
return;
if (lastActiveFilter != -1)
activeFilters[lastActiveFilter].end();
finished = true;
}
At this point (finished==true),tomcat will not send
/**
* End the current request. It is acceptable to write extra bytes using
* buffer.doWrite during the execution of this method.
*/
@Override
public long end()
throws IOException {
// Write end chunk
buffer.doWrite(END_CHUNK, null);
return 0;
}
So the error occours.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] still content-length header with chunked
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
Konstantin Kolinko <kn...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Konstantin Kolinko <kn...@gmail.com> ---
I do not see any bug here.
The request has Content-Length.
The response has "Transfer-Encoding: chunked" and does not have a
Content-Length. This is all as expected.
Read the HTTP protocol specification and ask you question on the users mailing
list. Bugzilla is not a support forum.
https://wiki.apache.org/tomcat/Specifications#HTTP
https://tools.ietf.org/html/rfc7230#section-4.1
http://tomcat.apache.org/bugreport.html#Bugzilla_is_not_a_support_forum
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
Chuck Caldarale <ch...@unisys.com> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] still content-length header with chunked
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #4 from Christopher Schultz <ch...@christopherschultz.net> ---
What code do you have that results in a non-zero chunk followed by *no* final
zero-byte chunk?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #24 from Christopher Schultz <ch...@christopherschultz.net> ---
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #14 from Ty <ty...@gmail.com> ---
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
Christopher Schultz <ch...@christopherschultz.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #19 from Christopher Schultz <ch...@christopherschultz.net> ---
Tomcat 7.0.76 chokes on this JSP in the way that qixiaobo.nj@gmail.com has
described. Here are the TCP responses from Tomcat 7 captured using Wireshark:
Packet 1:
0000 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 GMT....20
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:
0000 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] still content-length header with chunked
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #6 from qixiaobo.nj@gmail.com ---
case CLOSE_NOW: {
// Block further output
getOutputBuffer().finished = true;
setErrorState(ErrorState.CLOSE_NOW, null);
break;
}
public void endRequest()
throws IOException {
if (!committed) {
// Send the connector a request for commit. The connector should
// then validate the headers, send them (using sendHeader) and
// set the filters accordingly.
response.action(ActionCode.COMMIT, null);
}
if (finished)
return;
if (lastActiveFilter != -1)
activeFilters[lastActiveFilter].end();
finished = true;
}
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #16 from qixiaobo.nj@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #21 from Christopher Schultz <ch...@christopherschultz.net> ---
(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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |NEEDINFO
--- Comment #11 from Mark Thomas <ma...@apache.org> ---
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #22 from Mark Thomas <ma...@apache.org> ---
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
Konstantin Kolinko <kn...@gmail.com> 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 <kn...@gmail.com> ---
Updated the SUMMARY field.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] still content-length header with chunked
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
--- Comment #3 from qixiaobo.nj@gmail.com ---
Created attachment 34772
--> https://bz.apache.org/bugzilla/attachment.cgi?id=34772&action=edit
error request
without 0-sized chunk
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60750] A response that uses Transfer-Encoding: chunked is
missing the last zero-length chunk
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60750
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #17 from Mark Thomas <ma...@apache.org> ---
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org