Re: Tomcat NIO : CometProcessor
Filip Hanik - Dev Lists wrote: you're wrong, I believe it is chunk-header:blablaCRLF chunk-dataCRLF The spec says chunk = chunk-size [ chunk-extension ] CRLF chunk-data CRLF Hence, the request that was posted here, should have been 16bytes header, not 18 Whoops - you are correct. Somehow I overlooked that second CRLF when I checked 3.1.6. I should have checked an implementation and not just the spec... (The CRLF after chunk-data exists mostly to make any optional trailers easier to read, presumably.) So yes, the chunk-size in the posted request was wrong. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat NIO : CometProcessor
you're wrong, I believe it is chunk-header:blablaCRLF chunk-dataCRLF The spec says chunk = chunk-size [ chunk-extension ] CRLF chunk-data CRLF Hence, the request that was posted here, should have been 16bytes header, not 18 Filip On 04/01/2010 11:23 AM, Michael Wojcik wrote: Filip Hanik - Dev Lists wrote: I just skimmed this through, but from what I remember, the CRLF after /xml should not be counted into your chunk header No, the chunk-size is the entire length of the chunk. Since a chunked content-body can include any sort of data, it wouldn't make sense to exclude trailing whitespace characters - the content might not be of a type where whitespace characters were defined. See RFC 2616 3.6.1: chunk-data = chunk-size(OCTET) There must be exactly as many octets as specified in chunk-size. What I don't see in the trace are the zero-size chunks that terminate the chunked content-bodies. In frame 12, the client closes the connection (sends a FIN); that would appear to be why Tomcat is reporting the client closed the connection. Of course this is only a half-close, and the server *could* still send a response, but RFC 2616 doesn't acknowledge the half-close mechanism in TCP. From 4.4: 5.By the server closing the connection. (Closing the connection cannot be used to indicate the end of a request body, since that would leave no possibility for the server to send back a response.) This is, depending on your viewpoint, an error, oversight, or restriction in HTTP; but in effect it means that if the client closes its end of the conversation after sending a request but before receiving a response, the the server is free to consider the connection closed (even though it isn't) and discard the request. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat NIO : CometProcessor
Filip Hanik - Dev Lists wrote: I just skimmed this through, but from what I remember, the CRLF after /xml should not be counted into your chunk header No, the chunk-size is the entire length of the chunk. Since a chunked content-body can include any sort of data, it wouldn't make sense to exclude trailing whitespace characters - the content might not be of a type where whitespace characters were defined. See RFC 2616 3.6.1: chunk-data = chunk-size(OCTET) There must be exactly as many octets as specified in chunk-size. What I don't see in the trace are the zero-size chunks that terminate the chunked content-bodies. In frame 12, the client closes the connection (sends a FIN); that would appear to be why Tomcat is reporting the client closed the connection. Of course this is only a half-close, and the server *could* still send a response, but RFC 2616 doesn't acknowledge the half-close mechanism in TCP. From 4.4: 5.By the server closing the connection. (Closing the connection cannot be used to indicate the end of a request body, since that would leave no possibility for the server to send back a response.) This is, depending on your viewpoint, an error, oversight, or restriction in HTTP; but in effect it means that if the client closes its end of the conversation after sending a request but before receiving a response, the the server is free to consider the connection closed (even though it isn't) and discard the request. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat NIO : CometProcessor
hi Chris, if the connection is closed, most likely there is some sort of data error somewhere. Record your transaction with Wireshark, and we can examine it. Low latency http, meaning sending traffic back and forth should be possible within the body of the request Filip On 03/31/2010 07:01 AM, Christian Pfeiffer wrote: Hello, I just tried to use the tomcat nio and wondered if it is possible to use client and server pushes through the same socket connection? Or if I have to establish to connections for that purpose. In the end the client should be able to receive notification from server (server push) and also be able to request certain things. As I understood the Low Latency HTTP document it should be possible. Has anyone any advice for me, currently the connection gets closed after the second request from client with error CLIENT_DISCONNECTED. Thanks in advance Chris. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat NIO : CometProcessor
Hey Filip, thanks for your swift response. Wireshark tells me: //Client// POST /url/servlet HTTP/1.1 Host: localhost:8080 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.13) Gecko/2009080315 Ubuntu/9.04 (jaunty) Firefox/3.0.13 Transfer-Encoding: chunked 145 some xml/some xml //Server// HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=F9A0B9BAB695EDB6C51253A24D8989D9; Path=/streamcam_gwt Transfer-Encoding: chunked Date: Mon, 29 Mar 2010 15:44:25 GMT 9a some answer/some answer //Client// 8E second xml/second xml beside the hex values which are not set properly, cause I changed the xml for the sake of simplicity it should be fine right? Or do I miss something? BTW the last message(second xml) isnt examined by my servlet, there I already receive event Client_Disconnected instead of a read I expected. Let me know if you need more information. Thanks in advance Chris. Filip Hanik - Dev Lists schrieb: hi Chris, if the connection is closed, most likely there is some sort of data error somewhere. Record your transaction with Wireshark, and we can examine it. Low latency http, meaning sending traffic back and forth should be possible within the body of the request Filip On 03/31/2010 07:01 AM, Christian Pfeiffer wrote: Hello, I just tried to use the tomcat nio and wondered if it is possible to use client and server pushes through the same socket connection? Or if I have to establish to connections for that purpose. In the end the client should be able to receive notification from server (server push) and also be able to request certain things. As I understood the Low Latency HTTP document it should be possible. Has anyone any advice for me, currently the connection gets closed after the second request from client with error CLIENT_DISCONNECTED. Thanks in advance Chris. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat NIO : CometProcessor
I would need the raw data, not copy paste, I can't make anything out of that. Or if you have, a simple test case. Filip On 03/31/2010 07:57 AM, Christian Pfeiffer wrote: Hey Filip, thanks for your swift response. Wireshark tells me: //Client// POST /url/servlet HTTP/1.1 Host: localhost:8080 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.13) Gecko/2009080315 Ubuntu/9.04 (jaunty) Firefox/3.0.13 Transfer-Encoding: chunked 145 some xml/some xml //Server// HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=F9A0B9BAB695EDB6C51253A24D8989D9; Path=/streamcam_gwt Transfer-Encoding: chunked Date: Mon, 29 Mar 2010 15:44:25 GMT 9a some answer/some answer //Client// 8E second xml/second xml beside the hex values which are not set properly, cause I changed the xml for the sake of simplicity it should be fine right? Or do I miss something? BTW the last message(second xml) isnt examined by my servlet, there I already receive event Client_Disconnected instead of a read I expected. Let me know if you need more information. Thanks in advance Chris. Filip Hanik - Dev Lists schrieb: hi Chris, if the connection is closed, most likely there is some sort of data error somewhere. Record your transaction with Wireshark, and we can examine it. Low latency http, meaning sending traffic back and forth should be possible within the body of the request Filip On 03/31/2010 07:01 AM, Christian Pfeiffer wrote: Hello, I just tried to use the tomcat nio and wondered if it is possible to use client and server pushes through the same socket connection? Or if I have to establish to connections for that purpose. In the end the client should be able to receive notification from server (server push) and also be able to request certain things. As I understood the Low Latency HTTP document it should be possible. Has anyone any advice for me, currently the connection gets closed after the second request from client with error CLIENT_DISCONNECTED. Thanks in advance Chris. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat NIO : CometProcessor
Here the raw data: No. TimeSourceDestination Protocol Info 1 0.00127.0.0.1 127.0.0.1 TCP 46356 http-alt [SYN] Seq=0 Win=32792 Len=0 MSS=16396 TSV=5912087 TSER=0 WS=6 Frame 1 (74 bytes on wire, 74 bytes captured) Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1) Transmission Control Protocol, Src Port: 46356 (46356), Dst Port: http-alt (8080), Seq: 0, Len: 0 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..E. 0010 00 3c b1 bc 40 00 40 06 8a fd 7f 00 00 01 7f 00 .@.@. 0020 00 01 b5 14 1f 90 33 e8 87 ab 00 00 00 00 a0 02 ..3. 0030 80 18 c8 e4 00 00 02 04 40 0c 04 02 08 0a 00 5a @..z 0040 36 17 00 00 00 00 01 03 03 06 6. No. TimeSourceDestination Protocol Info 2 0.19127.0.0.1 127.0.0.1 TCP http-alt 46356 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=16396 TSV=5912087 TSER=5912087 WS=6 Frame 2 (74 bytes on wire, 74 bytes captured) Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1) Transmission Control Protocol, Src Port: http-alt (8080), Dst Port: 46356 (46356), Seq: 0, Ack: 1, Len: 0 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..E. 0010 00 3c 00 00 40 00 40 06 3c ba 7f 00 00 01 7f 00 .@.@ 0020 00 01 1f 90 b5 14 34 0e e9 03 33 e8 87 ac a0 12 ..4...3. 0030 80 00 75 68 00 00 02 04 40 0c 04 02 08 0a 00 5a ..uh@..z 0040 36 17 00 5a 36 17 01 03 03 06 6..Z6. No. TimeSourceDestination Protocol Info 3 0.35127.0.0.1 127.0.0.1 TCP 46356 http-alt [ACK] Seq=1 Ack=1 Win=32832 Len=0 TSV=5912087 TSER=5912087 Frame 3 (66 bytes on wire, 66 bytes captured) Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1) Transmission Control Protocol, Src Port: 46356 (46356), Dst Port: http-alt (8080), Seq: 1, Ack: 1, Len: 0 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..E. 0010 00 34 b1 bd 40 00 40 06 8b 04 7f 00 00 01 7f 00 @.@. 0020 00 01 b5 14 1f 90 33 e8 87 ac 34 0e e9 04 80 10 ..3...4. 0030 02 01 5c 8b 00 00 01 01 08 0a 00 5a 36 17 00 5a ..\Z6..Z 0040 36 17 6. No. TimeSourceDestination Protocol Info 4 0.000676127.0.0.1 127.0.0.1 TCP [TCP segment of a reassembled PDU] Frame 4 (193 bytes on wire, 193 bytes captured) Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1) Transmission Control Protocol, Src Port: 46356 (46356), Dst Port: http-alt (8080), Seq: 1, Ack: 1, Len: 127 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..E. 0010 00 b3 b1 be 40 00 40 06 8a 84 7f 00 00 01 7f 00 @.@. 0020 00 01 b5 14 1f 90 33 e8 87 ac 34 0e e9 04 80 18 ..3...4. 0030 02 01 fe a7 00 00 01 01 08 0a 00 5a 36 17 00 5a ...Z6..Z 0040 36 17 50 4f 53 54 20 2f 73 74 72 65 61 6d 63 61 6.POST /streamca 0050 6d 5f 67 77 74 2f 73 74 72 65 61 6d 63 61 6d 5f m_gwt/streamcam_ 0060 67 77 74 2f 58 4d 4c 41 63 65 43 61 72 64 20 48 gwt/XMLAceCard H 0070 54 54 50 2f 31 2e 31 0d 0a 48 6f 73 74 3a 20 6c TTP/1.1..Host: l 0080 6f 63 61 6c 68 6f 73 74 0d 0a 55 73 65 72 2d 41 ocalhost..User-A 0090 67 65 6e 74 3a 20 4d 6f 7a 69 6c 6c 61 2f 34 2e gent: Mozilla/4. 00a0 30 0d 0a 54 72 61 6e 73 66 65 72 2d 45 6e 63 6f 0..Transfer-Enco 00b0 64 69 6e 67 3a 20 63 68 75 6e 6b 65 64 0d 0a 0d ding: chunked... 00c0 0a. No. TimeSourceDestination Protocol Info 5 0.000685127.0.0.1 127.0.0.1 TCP http-alt 46356 [ACK] Seq=1 Ack=128 Win=32768 Len=0 TSV=5912087 TSER=5912087 Frame 5 (66 bytes on wire, 66 bytes captured) Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1) Transmission Control Protocol, Src Port: http-alt (8080), Dst Port: 46356 (46356), Seq: 1, Ack: 128, Len: 0 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..E. 0010 00 34 df 13 40 00 40 06 5d ae 7f 00 00 01 7f 00 @.@.]... 0020 00 01 1f 90 b5 14 34 0e e9 04 33
Re: Tomcat NIO : CometProcessor
On 03/31/2010 09:29 AM, Christian Pfeiffer wrote: 31 32 Let's take a look at the data you are sending 0040 36 17 31 32 0d 0a 3c 78 6d 6c 3e 48 65 6c 6c 6f 6.12..xmlHello 0050 3c 2f 78 6d 6c 3e 0d 0a /xml.. Your Chunk header: 31 32 That represents : 12 Which means, Tomcat will expect 18 bytes after the 0d 0a The data you send: 0040 3c 78 6d 6c 3e 48 65 6c 6c 6f xmlHello 0050 3c 2f 78 6d 6c 3e /xml I count 16 bytes. I just skimmed this through, but from what I remember, the CRLF after /xml should not be counted into your chunk header Filip - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
