Re: Connection:close request returns a response without any content-length or Transfer-Encoding: chunked
Hi Johnny, I am just retrieving the default root page of tomcat: GET / HTTP/1.1 I understand what you mean, but that's the default tomcat page. So, I do not really see what's difficult in getting the content-length. I am not using any servlet... It's when I am accessing http://127.0.0.1:8080 . Regards, Eric On 5/21/07, Johnny Kewl [EMAIL PROTECTED] wrote: Hi Eric... again...I dont think its a bug... Have you checked that the Servlet is setting the content length. ie response.setContentLength(theByteLength); This is the Javadoc comments from the actual Tomcat src code... * pThe servlet container must write the headers before * committing the response, because in HTTP the headers must be sent * before the response body. * * pWhere possible, set the Content-Length header (with the * [EMAIL PROTECTED] javax.servlet.ServletResponse#setContentLength} method), * to allow the servlet container to use a persistent connection * to return its response to the client, improving performance. * The content length is automatically set if the entire response fits * inside the response buffer. * * pWhen using HTTP 1.1 chunked encoding (which means that the response * has a Transfer-Encoding header), do not set the Content-Length header. Can you see what its saying... ie if you dont explicitly set setContentLength... its just luck whether you get it or not. Because the system will try maintain a keep alive IF IT FITS IN THE BUFFER theres a header... if not... the system cant work it out because when the buffer is full... it has to let it go... so as soon as it gets to that state **without** a setContentLength... its going to revert back to http 1.0 and close the connection. ... and it will not display the ContentLength header. Can you see that even if the server could calculate it across multiple buffers... its no good... because the browser will already have the headers from the first buffer and servlet is still calculating!! So... are you sure that your servlet has EXPLICITLY ***setContentLength(theByteLength);*** If its not your servlet... and you cant change it can you see the kludge... ie if you make the buffer size enormous... you will get headers, but that is really crap coding... if you can, fix the servlet source. Can you post the servlet source?... I think the problem is there... - Original Message - From: Eric Deshayes [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Monday, May 21, 2007 3:37 AM Subject: Re: Connection:close request returns a response without any content-length or Transfer-Encoding: chunked Hi Johnny, thanks for your help. By dichotomy, I've managed that the bug has been fixed in Tomcat 5.5.16. However, I could not find any bug even by having a look at the tomcat 5.5changelog. Eric - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- ERIC DESHAYES
Re: Connection:close request returns a response without any content-length or Transfer-Encoding: chunked
Hi Johnny, thanks for your help. By dichotomy, I've managed that the bug has been fixed in Tomcat 5.5.16. However, I could not find any bug even by having a look at the tomcat 5.5changelog. Eric On 5/18/07, Johnny Kewl [EMAIL PROTECTED] wrote: Just a footnote coz i suddenly realized wot may be happening Because a browser may only support http 1.0... and or the content lengths are not been set in the server... if you have progress scripts in your page... you always have to check for divide by zero... which I imagine is your problem. In a good browser you will sometime see it downloading by the the length is ? The programmer forgot to set the length ;) or youre in a http 1.0server (IIS... no just kidding ;) - Original Message - From: Johnny Kewl [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, May 18, 2007 9:46 PM Subject: Re: Connection:close request returns a response without any content-length or Transfer-Encoding: chunked I havnt kept up http standards so this is a guess as usual ;) In http 1.0 thats how the server told the browser that the transmission was over it closed the connection. So if its defaulting to the old way slamming down the telephone... context length doesnt mean anything... so the server wont bother... its the 1.0 spec. Then they got smart with keep alives... server reaction time is improved greatly... no http connection to reestablish... but then they had to include a context length otherwise the browser wont know when its got it. So just from that if your servlet program does not set the context length header... the server has no choice but to go back to the old 1.0 spec and slam down the phone. Sometimes u dont know the length like possibly when streaming an encrypted stream in that case I imagine tomcat will choose (I need help here people!) so if its short server will go... user didnt tell me how long this is... slam down phone... OR... its going to go is this guy nuts... the thing is 10 megs and I dont know when its going to end and it will start chunking... (I think). Anyway I think wot you seeing is normal if you setting the Content-Length... and not getting it... that doesnt make sense... but if not... tomcat is just trying to do the best it can - Original Message - From: Eric Deshayes [EMAIL PROTECTED] To: users@tomcat.apache.org Sent: Friday, May 18, 2007 6:23 PM Subject: Connection:close request returns a response without any content-length or Transfer-Encoding: chunked Can anyone help me about that? Regards, Eric Sorry, i forgot to mention I was working with JBoss 4.0.3 SP1, so I assume Tomcat 5.5.9. Here are some example to illustrate my case. The first one i my problem. Is that a fix bug? if so, In which version of TOmcat has it been fixed? It seems to work in the latest tomcat 5.5 version (5.5.23) If not, am I missing something from the Http specs? Regards, Eric Example with Tomcat 5.5.9 (connection : close and NO content-length or Transfer-Encoding provided): GET / HTTP/1.1 Host: 127.0.0.1:18080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3 ) Gecko/20070309 Firefox/2.0.0.3 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q= 0.9 ,text/plain;q=0.8,image/png,*/*;q=0.5 Connection: close HTTP/1.1 200 OK Server: Apache-Coyote/1.1 X-Powered-By: Servlet 2.4; JBoss-4.0.3SP1 (build: CVSTag=JBoss_4_0_3_SP1 date=200510231751)/Tomcat-5.5 Set-Cookie: JSESSIONID=7B90F594FCF9AB6A6AF690352724A94F; Path=/ Content-Type: text/html;charset=ISO-8859-1 Date: Thu, 17 May 2007 00:19:04 GMT Connection: close Second example with Tomcat 5.5.9 (connection : close and Transfer-Encoding provided) GET / HTTP/1.1 Host: 127.0.0.1:18080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3 ) Gecko/20070309 Firefox/2.0.0.3 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q= 0.9 ,text/plain;q=0.8,image/png,*/*;q=0.5 HTTP/1.1 200 OK Server: Apache-Coyote/1.1 X-Powered-By: Servlet 2.4; JBoss-4.0.3SP1 (build: CVSTag=JBoss_4_0_3_SP1 date=200510231751)/Tomcat-5.5 Set-Cookie: JSESSIONID=8306B59382F5277A0782B98F9362213A; Path=/ Content-Type: text/html;charset=ISO-8859-1 Transfer-Encoding: chunked Date: Thu, 17 May 2007 00:19:25 GMT Finally, I have tried with the latest Tomcat version 5.5.23 (no connection : close and content-length provided) GET / HTTP/1.1 Host: 127.0.0.1:18080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3 ) Gecko/20070309 Firefox/2.0.0.3 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9 ,text/plain;q=0.8,image/png,*/*;q=0.5 HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/html;charset=ISO-8859-1 Content-Length: 8132 Date: Thu, 17 May 2007 00:19:48 GMT Another test with Tomcat 5.5.23 (connection : close and content-length provided
Connection:close request returns a response without any content-length or Transfer-Encoding: chunked
Can anyone help me about that? Regards, Eric Sorry, i forgot to mention I was working with JBoss 4.0.3 SP1, so I assume Tomcat 5.5.9. Here are some example to illustrate my case. The first one i my problem. Is that a fix bug? if so, In which version of TOmcat has it been fixed? It seems to work in the latest tomcat 5.5 version (5.5.23) If not, am I missing something from the Http specs? Regards, Eric Example with Tomcat 5.5.9 (connection : close and NO content-length or Transfer-Encoding provided): GET / HTTP/1.1 Host: 127.0.0.1:18080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q= 0.9 ,text/plain;q=0.8,image/png,*/*;q=0.5 Connection: close HTTP/1.1 200 OK Server: Apache-Coyote/1.1 X-Powered-By: Servlet 2.4; JBoss-4.0.3SP1 (build: CVSTag=JBoss_4_0_3_SP1 date=200510231751)/Tomcat-5.5 Set-Cookie: JSESSIONID=7B90F594FCF9AB6A6AF690352724A94F; Path=/ Content-Type: text/html;charset=ISO-8859-1 Date: Thu, 17 May 2007 00:19:04 GMT Connection: close Second example with Tomcat 5.5.9 (connection : close and Transfer-Encoding provided) GET / HTTP/1.1 Host: 127.0.0.1:18080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q= 0.9 ,text/plain;q=0.8,image/png,*/*;q=0.5 HTTP/1.1 200 OK Server: Apache-Coyote/1.1 X-Powered-By: Servlet 2.4; JBoss-4.0.3SP1 (build: CVSTag=JBoss_4_0_3_SP1 date=200510231751)/Tomcat-5.5 Set-Cookie: JSESSIONID=8306B59382F5277A0782B98F9362213A; Path=/ Content-Type: text/html;charset=ISO-8859-1 Transfer-Encoding: chunked Date: Thu, 17 May 2007 00:19:25 GMT Finally, I have tried with the latest Tomcat version 5.5.23 (no connection : close and content-length provided) GET / HTTP/1.1 Host: 127.0.0.1:18080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9 ,text/plain;q=0.8,image/png,*/*;q=0.5 HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/html;charset=ISO-8859-1 Content-Length: 8132 Date: Thu, 17 May 2007 00:19:48 GMT Another test with Tomcat 5.5.23 (connection : close and content-length provided): GET / HTTP/1.1 Host: 127.0.0.1:18080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9 ,text/plain;q=0.8,image/png,*/*;q=0.5 Connection: close HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/html;charset=ISO-8859-1 Content-Length: 8132 Date: Thu, 17 May 2007 00:20:10 GMT Connection: close Hi, is that normal that when the header of my request contains Connection:close, the response I get does not contain any content-length or Transfer-Encoding header?? When, the Connection: close header is not a header of the request, I get either a content-length or Transfer-Encoding header. Thanks for your help!! Eric -- -- ERIC DESHAYES -- -- ERIC DESHAYES -- -- ERIC DESHAYES
Re: Connection:close request returns a response without any content-length or Transfer-Encoding: chunked
Sorry, i forgot to mention I was working with JBoss 4.0.3 SP1, so I assume Tomcat 5.5.9. Here are some example to illustrate my case. The first one i my problem. Is that a fix bug? if so, In which version of TOmcat has it been fixed? It seems to work in the latest tomcat 5.5 version (5.5.23) If not, am I missing something from the Http specs? Regards, Eric Example with Tomcat 5.5.9 (connection : close and NO content-length or Transfer-Encoding provided): GET / HTTP/1.1 Host: 127.0.0.1:18080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9 ,text/plain;q=0.8,image/png,*/*;q=0.5 Connection: close HTTP/1.1 200 OK Server: Apache-Coyote/1.1 X-Powered-By: Servlet 2.4; JBoss-4.0.3SP1 (build: CVSTag=JBoss_4_0_3_SP1 date=200510231751)/Tomcat-5.5 Set-Cookie: JSESSIONID=7B90F594FCF9AB6A6AF690352724A94F; Path=/ Content-Type: text/html;charset=ISO-8859-1 Date: Thu, 17 May 2007 00:19:04 GMT Connection: close Second example with Tomcat 5.5.9 (connection : close and Transfer-Encoding provided) GET / HTTP/1.1 Host: 127.0.0.1:18080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9 ,text/plain;q=0.8,image/png,*/*;q=0.5 HTTP/1.1 200 OK Server: Apache-Coyote/1.1 X-Powered-By: Servlet 2.4; JBoss-4.0.3SP1 (build: CVSTag=JBoss_4_0_3_SP1 date=200510231751)/Tomcat-5.5 Set-Cookie: JSESSIONID=8306B59382F5277A0782B98F9362213A; Path=/ Content-Type: text/html;charset=ISO-8859-1 Transfer-Encoding: chunked Date: Thu, 17 May 2007 00:19:25 GMT Finally, I have tried with the latest Tomcat version 5.5.23 (no connection : close and content-length provided) GET / HTTP/1.1 Host: 127.0.0.1:18080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9 ,text/plain;q=0.8,image/png,*/*;q=0.5 HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/html;charset=ISO-8859-1 Content-Length: 8132 Date: Thu, 17 May 2007 00:19:48 GMT Another test with Tomcat 5.5.23 (connection : close and content-length provided): GET / HTTP/1.1 Host: 127.0.0.1:18080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9 ,text/plain;q=0.8,image/png,*/*;q=0.5 Connection: close HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/html;charset=ISO-8859-1 Content-Length: 8132 Date: Thu, 17 May 2007 00:20:10 GMT Connection: close On 5/16/07, Eric Deshayes [EMAIL PROTECTED] wrote: Hi, is that normal that when the header of my request contains Connection:close, the response I get does not contain any content-length or Transfer-Encoding header?? When, the Connection: close header is not a header of the request, I get either a content-length or Transfer-Encoding header. Thanks for your help!! Eric -- -- ERIC DESHAYES -- -- ERIC DESHAYES
