tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <cos...@gmail.com>
Subject Re: Tomcat Comet Model
Date Sat, 17 Jun 2006 00:51:25 GMT
Not sure I understand all details here - but chunking seems like a better
solution
than sending a bad Content-Length.

Sending a too large or incorrect content-length may break a lot of things (
and be rejected,
affect proxies, etc ).

Costin


On 6/16/06, Filip Hanik - Dev Lists <devlists@hanik.com> wrote:
>
> Remy Maucherat wrote:
> > Filip Hanik - Dev Lists wrote:
> >> yes, but to do so, you would be required to pre calculate the content
> >> length for the 2 (or N events), and if the server hasn't responded
> >> (since its async) you can't send the 2nd event as you could start a
> >> new HTTP request on the same connection when there hasn't been a
> >> response. So to open your self up for async push for both client and
> >> server, you omit content length, or set it to an extremely large value.
> >>
> >> see where I am getting it?
> >
> > Yes, I do.
> >
> > Comet "designers" got the idea too (most likely they want to work
> > somewhat with proxies), and so Comet must use chunking on input (as
> > any decent HTTP user agent would do automagically) and output (Tomcat
> > will do it automagically too). This way it works without breaking the
> > protocol and without having to compute the total length of the
> > request/response beforehand. Of course, you can have easy testing of
> > the code by using (fake) large content-length values like I did, but
> > that's for local testing only.
> how can tomcat know the Content-Length down to the client, when servlets
> and JSP call flushBuffer, or the response(s) are two big to fit in the
> buffer?
> At that point, its up to the servlet programmer to send the content
> length, but again, how would they know in advance the size of the total
> response,
>
> so chunking becomes difficult
> Filip
>
> >
> > Rémy
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
>
> --
>
>
> Filip Hanik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message