tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: Comet: problem with request.getParameter() in Comet POST requests
Date Wed, 02 May 2007 18:25:44 GMT
Reich, Matthias wrote:
>  
>
>   
>> -----Original Message-----
>> From: Sebastiaan van Erk [mailto:sebster@sebster.com] 
>> Sent: Friday, April 27, 2007 7:24 PM
>> To: Tomcat Users List
>> Subject: Re: Comet: problem with request.getParameter() in 
>> Comet POST requests
>>
>>
>>     
>>> GET parameters, ie parameters in the URL will work.
>>> However, using Comet you shouldn't rely on parameters in 
>>>       
>> the body, the 
>>     
>>> body if for you usage, and your usage alone.
>>>       
>> Seems to me that this is a pretty common use case though with AJAX 
>> server side push: request, wait, response.
>> Comet is used to free the http thread while waiting, otherwise the 
>> server would be out of http threads in no time.
>> The data posted is often in POST form (a scripted form post).
>>     
>>> You can still invoke getReader or getInputStream without actually 
>>> reading from it, if that causes the parse to happen.
>>>       
>> Yes, that is my current workaround, I use READ events and the 
>> Content-Length header to parse the parameters myself.
>>     
>
> Wouldn't every application which isn't as dumb as the chat example
> (which does not care about the content it reads but simply passes it
> back to it's clients) need to implement it's own mechanism to check
> whether there is enough input available to start parsing a chunk of
> data?
>   
huh? This exact same problem exist with regular servlets, and has 
existed for the last 8 years.
Filip

> According to my current understanding of Comet a READ event will be
> triggered after some tcp packet was received from the client.
> Thus, even if a client has sent a complete chunk of data (e.g. a SOAP
> request), the server side cannot be sure that it is completely available
> for parsing when a READ event is triggered.
>
> Thus, each application must implement it's own http like protocol to
> wrap each chunk of data transferred to the server:
> - The client must send the number of bytes of the following chunk before
> the actual chunk is sent.
> To be able to do this, it must care about content encoding (e.g. write
> character based data to a ByteArrayOutputStream first, determine it's
> length, send the number of bytes, and then the content of the byte
> array)
> - The servlet must read the length, allocate a byte buffer and start
> reading into the buffer.
> - Only if it has received a READ event that delivers the last expected
> byte of the chunk, the content of the byte buffer can be converted into
> a String (or another character based sequence) according to the
> character encoding specified by the client, and finally parsed.
>
> Is it really the intention of Comet that each application must care
> about these things?
>
> Is there no way to enable a Servlet to do a blocking read if it
> recognizes that a client has sent a chunk of data?
> It would not block for a long time in that situation (only until the
> missing tcp packets of the actual chunk have arrived). This would allow
> a much more convenient handling of input for most applications.
>
> Matthias
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message