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.0 server (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):
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



---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to