You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Paul Dumais <pa...@rovemobile.com> on 2007/12/12 14:33:18 UTC
Comet position of CRLF in request chunks
I am using Comet for by directional communication between a native java
client and a tomcat server.
I noticed that when sending chunks to the Tomcat server over the request
stream Tomcat does not like to receive a CRLF at the end of a chunk, it
is only accepting the CRLF at the beginning of the following chunk.
According to rfc2616 the CRLF should be at the end of each chunk:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1
For example tomcat likes this type of chunk to be sent:
CRLF chunk-size CRLF chunk-data
But it does not like this format:
chunk-size CRLF chunk-data CRLF
Tomcat basically fires a Comet Read event to the CometProcessor with the
chunk data, but afterward fires an ERROR event with subevent type
IOEXCEPTION. I have tested this with Tomcat 6.0.14 as well as the trunk
(Dec 11th, 2007).
Here is the sample code of a java client that connects to a simple
CometEcho processor:
Socket s = new Socket("localhost", 8080);
OutputStream out = s.getOutputStream();
out.write(("POST /CometEcho HTTP/1.1\r\n" +
"Host: localhost:8080\r\n" +
"Transfer-Encoding: chunked\r\n" +
"\r\n").getBytes());
out.flush();
boolean first = true;
BufferedReader reader = new BufferedReader(new
InputStreamReader(System.in));
while (s.isConnected()) {
String line = reader.readLine();
//String chunk =
(first?"":"\r\n")+Integer.toHexString(line.length())+"\r\n"+line; //
tomcat only accepts this kind of chunk
String chunk =
Integer.toHexString(line.length())+"\r\n"+line+"\r\n"; // this format
should work according to rfc2616
first = false;
out.write(chunk.getBytes());
out.flush();
}
I was wondering if someone could explain this, and if this is by design,
or if I am using Comet incorrectly.
Thank you,
Paul
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Comet position of CRLF in request chunks
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
I've proposed a patch for this behavior
http://svn.apache.org/viewvc?view=rev&revision=604274
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?r1=604274&r2=604273&pathrev=604274
Filip
Filip Hanik - Dev Lists wrote:
> that's correct, that's how it works.
> I'll go over the specs to see if this is not what it is supposed to do
>
> Filip
>
> Paul Dumais wrote:
>> I am using Comet for by directional communication between a native java
>> client and a tomcat server.
>>
>> I noticed that when sending chunks to the Tomcat server over the request
>> stream Tomcat does not like to receive a CRLF at the end of a chunk, it
>> is only accepting the CRLF at the beginning of the following chunk.
>>
>> According to rfc2616 the CRLF should be at the end of each chunk:
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1
>>
>> For example tomcat likes this type of chunk to be sent:
>> CRLF chunk-size CRLF chunk-data
>>
>> But it does not like this format:
>> chunk-size CRLF chunk-data CRLF
>>
>> Tomcat basically fires a Comet Read event to the CometProcessor with the
>> chunk data, but afterward fires an ERROR event with subevent type
>> IOEXCEPTION. I have tested this with Tomcat 6.0.14 as well as the trunk
>> (Dec 11th, 2007).
>>
>> Here is the sample code of a java client that connects to a simple
>> CometEcho processor:
>>
>> Socket s = new Socket("localhost", 8080);
>> OutputStream out = s.getOutputStream();
>>
>> out.write(("POST /CometEcho HTTP/1.1\r\n" +
>> "Host: localhost:8080\r\n" +
>> "Transfer-Encoding: chunked\r\n" +
>> "\r\n").getBytes());
>> out.flush();
>>
>> boolean first = true;
>> BufferedReader reader = new BufferedReader(new
>> InputStreamReader(System.in));
>>
>> while (s.isConnected()) {
>> String line = reader.readLine();
>>
>> //String chunk =
>> (first?"":"\r\n")+Integer.toHexString(line.length())+"\r\n"+line; //
>> tomcat only accepts this kind of chunk
>>
>> String chunk =
>> Integer.toHexString(line.length())+"\r\n"+line+"\r\n"; // this format
>> should work according to rfc2616
>>
>> first = false;
>>
>> out.write(chunk.getBytes());
>> out.flush();
>> }
>>
>> I was wondering if someone could explain this, and if this is by design,
>> or if I am using Comet incorrectly.
>>
>> Thank you,
>> Paul
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Comet position of CRLF in request chunks
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
that's correct, that's how it works.
I'll go over the specs to see if this is not what it is supposed to do
Filip
Paul Dumais wrote:
> I am using Comet for by directional communication between a native java
> client and a tomcat server.
>
> I noticed that when sending chunks to the Tomcat server over the request
> stream Tomcat does not like to receive a CRLF at the end of a chunk, it
> is only accepting the CRLF at the beginning of the following chunk.
>
> According to rfc2616 the CRLF should be at the end of each chunk:
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1
>
> For example tomcat likes this type of chunk to be sent:
> CRLF chunk-size CRLF chunk-data
>
> But it does not like this format:
> chunk-size CRLF chunk-data CRLF
>
> Tomcat basically fires a Comet Read event to the CometProcessor with the
> chunk data, but afterward fires an ERROR event with subevent type
> IOEXCEPTION. I have tested this with Tomcat 6.0.14 as well as the trunk
> (Dec 11th, 2007).
>
> Here is the sample code of a java client that connects to a simple
> CometEcho processor:
>
> Socket s = new Socket("localhost", 8080);
> OutputStream out = s.getOutputStream();
>
> out.write(("POST /CometEcho HTTP/1.1\r\n" +
> "Host: localhost:8080\r\n" +
> "Transfer-Encoding: chunked\r\n" +
> "\r\n").getBytes());
> out.flush();
>
> boolean first = true;
> BufferedReader reader = new BufferedReader(new
> InputStreamReader(System.in));
>
> while (s.isConnected()) {
> String line = reader.readLine();
>
> //String chunk =
> (first?"":"\r\n")+Integer.toHexString(line.length())+"\r\n"+line; //
> tomcat only accepts this kind of chunk
>
> String chunk =
> Integer.toHexString(line.length())+"\r\n"+line+"\r\n"; // this format
> should work according to rfc2616
>
> first = false;
>
> out.write(chunk.getBytes());
> out.flush();
> }
>
> I was wondering if someone could explain this, and if this is by design,
> or if I am using Comet incorrectly.
>
> Thank you,
> Paul
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org