You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Filip Hanik - Dev Lists <de...@hanik.com> on 2006/06/17 01:27:23 UTC
Tomcat Comet Model
all, I have made a little image that would explain the idea I have (and
implemented today) for the Tomcat model, would like to get some feedback,
Remy and I already have an open dialogue, but its subjected under a
commit, so if you didn't read that one, this one has a nice pix
also available at http://www.halosg.com/Comet.png
this doesn't break the original Comet model, it is backwards compatible,
yet it extends a little bit further making it more useful for no latency
lagging
Filip
--
Filip Hanik
Re: Tomcat Comet Model
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Not sure I understand all details here - but chunking seems like a better
> solution
> than sending a bad Content-Length.
Indeed, you got it right, chunking is supposed to be used.
> Sending a too large or incorrect content-length may break a lot of things (
> and be rejected,
> affect proxies, etc ).
Yes, the only place content-length should be used is when testing with a
telnet.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat Comet Model, DOS example
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>>> Right now I'm not hot about reading the data first in the container:
>>> if done, it should be in InputBuffer,
>> yes, that is how I suggested it to be done. The AprBuffer was reading
>> the socket data in my checkin.
>>
>>> but could mean automagically discarding data, which could become a
>>> very sneaky problem if the user doesn't code the right way but is
>>> interested in the data.
>> yes, I prefer delivering the data. option 1
>
> The point of your patch was not to preread the data as you are now
> claiming, but instead about accepting entity bodies from invalid
> requests. As I said, I prefer the current mechanism.
I see your point, and fair enough, chunked is the way to go for multi
client requests, brings a question to my mind. my patch delivered the
data. but if you don't wanna do that, you should at least discard the
data and never invoke read, (and maybe even terminate the connection)
and this is the problem I'm trying to address, to deliver or not to
deliver the data I can live with, as you are correct on the content
length, that was just one part of it, its the loop I'm trying to avoid.
Lets name that problem 1.
Problem 2. If the client aborts its connection while the async servlet
is writing, we have yet another VM crash.
I believe problem 1 and 2 are all valid problems, and if you don't mind,
I'll delve deeper into these to see how we can avoid them. I'll provide
patches for review,
how does that sound,
Filip
--
Filip Hanik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat Comet Model, DOS example
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
>> Right now I'm not hot about reading the data first in the container:
>> if done, it should be in InputBuffer,
> yes, that is how I suggested it to be done. The AprBuffer was reading
> the socket data in my checkin.
>
>> but could mean automagically discarding data, which could become a
>> very sneaky problem if the user doesn't code the right way but is
>> interested in the data.
> yes, I prefer delivering the data. option 1
The point of your patch was not to preread the data as you are now
claiming, but instead about accepting entity bodies from invalid
requests. As I said, I prefer the current mechanism.
>> There are still some serious problems though, starting with the
>> current C2B and B2C converters which use far too much memory. I would
>> like to use the NIO converters instead, but they want to use
>> ByteBuffer and CharBuffer.
> yes, and ByteBuffer and CharBuffer have historically been slower than
> byte[] and char[], not sure if that is still the case.
I was talking about character encoding and decoding, which right now
sucks and is using tons of memory.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat Comet Model, DOS example
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> I agree, chunked would be the way to go for a communication.
>>
>> I reverted my fix, however, now TC6 has a DOS possibility, by
>> following these steps
>>
>> 1. Override CometServlet.read, always return true (you wanna serve N
>> client requests, and you don't know how many its gonna send, so this
>> is not unreasonable)
>
> I fail to see why doing that is reasonable: you're getting an event to
> read data, so you have to read it even if you're not going to use it
> (as in NIO).
yes, and since I am receiving the read event, I'm expecting data, no
data was available, so I return true to wait for it become available.
Tomcat fails to deliver the data, even though it issues a read(req,resp)
event.
Two solutions
1. Deliver the data (my reverted checkin)
2. Read the socket, discard the data, never call read
> Right now I'm not hot about reading the data first in the container:
> if done, it should be in InputBuffer,
yes, that is how I suggested it to be done. The AprBuffer was reading
the socket data in my checkin.
> but could mean automagically discarding data, which could become a
> very sneaky problem if the user doesn't code the right way but is
> interested in the data.
yes, I prefer delivering the data. option 1
>
> There are still some serious problems though, starting with the
> current C2B and B2C converters which use far too much memory. I would
> like to use the NIO converters instead, but they want to use
> ByteBuffer and CharBuffer.
yes, and ByteBuffer and CharBuffer have historically been slower than
byte[] and char[], not sure if that is still the case.
>
> Rémy
so where do we stand, you cool now? can I go back and work on my
checkin, improve it, and continue working on the Comet feature?
Filip
>
> ---------------------------------------------------------------------
> 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
Re: Tomcat Comet Model, DOS example
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> I agree, chunked would be the way to go for a communication.
>
> I reverted my fix, however, now TC6 has a DOS possibility, by following
> these steps
>
> 1. Override CometServlet.read, always return true (you wanna serve N
> client requests, and you don't know how many its gonna send, so this is
> not unreasonable)
I fail to see why doing that is reasonable: you're getting an event to
read data, so you have to read it even if you're not going to use it (as
in NIO). Right now I'm not hot about reading the data first in the
container: if done, it should be in InputBuffer, but could mean
automagically discarding data, which could become a very sneaky problem
if the user doesn't code the right way but is interested in the data.
There are still some serious problems though, starting with the current
C2B and B2C converters which use far too much memory. I would like to
use the NIO converters instead, but they want to use ByteBuffer and
CharBuffer.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat Comet Model, DOS example
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
I agree, chunked would be the way to go for a communication.
I reverted my fix, however, now TC6 has a DOS possibility, by following
these steps
1. Override CometServlet.read, always return true (you wanna serve N
client requests, and you don't know how many its gonna send, so this is
not unreasonable)
2. Client sends data with Content-Length
POST /comet?count=001 HTTP/1.1\r\n
Host: 127.0.0.1:8080
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1)
Gecko/20060124 Firefox/1.5.0.1\r\n
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
Keep-Alive: 300\r\n
Connection: keep-alive\r\n
Content-Type: text/plain\r\n
Content-Length: 16\r\n
\r\n
submit=value8888
3. client then sends any data (http request, garbage, anything)
4. Tomcat server hangs in a loop on that thread
5. Repeat steps 1-4 for as many as there are threads in the pool, and we
have DOS
Filip
Costin Manolache wrote:
> 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 <de...@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
>>
>>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.9.0/367 - Release Date: 6/16/2006
>
--
Filip Hanik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat Comet Model
Posted by Costin Manolache <co...@gmail.com>.
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 <de...@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
>
>
Re: Tomcat Comet Model
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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
Re: Tomcat Comet Model
Posted by Remy Maucherat <re...@apache.org>.
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.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat Comet Model
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> all, I have made a little image that would explain the idea I have
>> (and implemented today) for the Tomcat model, would like to get some
>> feedback,
>>
>> Remy and I already have an open dialogue, but its subjected under a
>> commit, so if you didn't read that one, this one has a nice pix
>> also available at http://www.halosg.com/Comet.png
>>
>> this doesn't break the original Comet model, it is backwards
>> compatible, yet it extends a little bit further making it more useful
>> for no latency lagging
>
> There is no difference at all, this is still Comet (yes, you can get
> two read events in a row).
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?
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat Comet Model
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
yes it is, the problem here is that Tomcat is initiating a
CometServlet.read when bogus data comes in after Content-Length has been
reached.
Filip
Andy Piper wrote:
> Bogus content-length is asking for trouble. IIRC it can cause SSL
> no-end of headaches.
>
> andy
>
> At 01:06 17/06/2006, Filip Hanik - Dev Lists wrote:
>> Lemme narrow everything down, and this will be short, I promise,
>>
>> it all boils down to the Content-Length header,
>> if this header is omitted then it wont be possible for the client to
>> send more than one request.
>>
>> The workaround for this, Content-Length: Integer.MAX_VALUE, this will
>> make the code accept more than one request
>>
>> If that is acceptible workaround, I can happily revert the commit.
>>
>> Filip
>>
>>
>>
>> Remy Maucherat wrote:
>>> Filip Hanik - Dev Lists wrote:
>>>> and that is the exact bug I fixed. Before the commit, you couldn't.
>>>> So to support your argument, you should be in favor of the commit.
>>>> not against.
>>>
>>> Ok, then post the request you are sending. The whole request must be
>>> a valid HTTP/1.1 request with a properly delimited body, rather than
>>> just a HTTP header, followed by random data.
>>>
>>> This is not a valid request, for example:
>>>
>>> GET /foo HTTP/1.1
>>> Host: bla
>>>
>>> my content (wait 10 s) more of my content
>>>
>>>>> I fail to see what your purpose is to step on my toes like this,
>>>>> and barge in with commit, when you didn't discuss anything.
>>>> not sure what your toes and the ASF owned repository have in common ;)
>>>
>>> To give an example: I suppose I could try committing random stuff to
>>> the clustering module.
>>>
>>>> We're discussing it now, you started it with a veto, and yes, i
>>>> could have used the endless discussion tactic to prove the bug, but
>>>> it was faster to come in with a solution.
>>>
>>> That's what you are doing right now, rather than convince me that
>>> you understand all the issues.
>>>
>>> Ok, I'm going to bed now, and then on WE. I hate it when people
>>> force me to stay up until 2AM on friday just because I made the
>>> mistake of checking my email before going to bed ...
>>>
>>> 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
>
> _______________________________________________________________________
> Notice: This email message, together with any attachments, may contain
> information of BEA Systems, Inc., its subsidiaries and affiliated
> entities, that may be confidential, proprietary, copyrighted and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
>
> ---------------------------------------------------------------------
> 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
Re: Tomcat Comet Model
Posted by Andy Piper <an...@bea.com>.
Bogus content-length is asking for trouble. IIRC
it can cause SSL no-end of headaches.
andy
At 01:06 17/06/2006, Filip Hanik - Dev Lists wrote:
>Lemme narrow everything down, and this will be short, I promise,
>
>it all boils down to the Content-Length header,
>if this header is omitted then it wont be
>possible for the client to send more than one request.
>
>The workaround for this, Content-Length:
>Integer.MAX_VALUE, this will make the code accept more than one request
>
>If that is acceptible workaround, I can happily revert the commit.
>
>Filip
>
>
>
>Remy Maucherat wrote:
>>Filip Hanik - Dev Lists wrote:
>>>and that is the exact bug I fixed. Before the
>>>commit, you couldn't. So to support your
>>>argument, you should be in favor of the commit. not against.
>>
>>Ok, then post the request you are sending. The
>>whole request must be a valid HTTP/1.1 request
>>with a properly delimited body, rather than
>>just a HTTP header, followed by random data.
>>
>>This is not a valid request, for example:
>>
>>GET /foo HTTP/1.1
>>Host: bla
>>
>>my content (wait 10 s) more of my content
>>
>>>>I fail to see what your purpose is to step on
>>>>my toes like this, and barge in with commit, when you didn't discuss anything.
>>>not sure what your toes and the ASF owned repository have in common ;)
>>
>>To give an example: I suppose I could try
>>committing random stuff to the clustering module.
>>
>>>We're discussing it now, you started it with a
>>>veto, and yes, i could have used the endless
>>>discussion tactic to prove the bug, but it was
>>>faster to come in with a solution.
>>
>>That's what you are doing right now, rather
>>than convince me that you understand all the issues.
>>
>>Ok, I'm going to bed now, and then on WE. I
>>hate it when people force me to stay up until
>>2AM on friday just because I made the mistake
>>of checking my email before going to bed ...
>>
>>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
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat Comet Model
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Lemme narrow everything down, and this will be short, I promise,
it all boils down to the Content-Length header,
if this header is omitted then it wont be possible for the client to
send more than one request.
The workaround for this, Content-Length: Integer.MAX_VALUE, this will
make the code accept more than one request
If that is acceptible workaround, I can happily revert the commit.
Filip
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> and that is the exact bug I fixed. Before the commit, you couldn't.
>> So to support your argument, you should be in favor of the commit.
>> not against.
>
> Ok, then post the request you are sending. The whole request must be a
> valid HTTP/1.1 request with a properly delimited body, rather than
> just a HTTP header, followed by random data.
>
> This is not a valid request, for example:
>
> GET /foo HTTP/1.1
> Host: bla
>
> my content (wait 10 s) more of my content
>
>>> I fail to see what your purpose is to step on my toes like this, and
>>> barge in with commit, when you didn't discuss anything.
>> not sure what your toes and the ASF owned repository have in common ;)
>
> To give an example: I suppose I could try committing random stuff to
> the clustering module.
>
>> We're discussing it now, you started it with a veto, and yes, i could
>> have used the endless discussion tactic to prove the bug, but it was
>> faster to come in with a solution.
>
> That's what you are doing right now, rather than convince me that you
> understand all the issues.
>
> Ok, I'm going to bed now, and then on WE. I hate it when people force
> me to stay up until 2AM on friday just because I made the mistake of
> checking my email before going to bed ...
>
> 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
Re: Tomcat Comet Model
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> and that is the exact bug I fixed. Before the commit, you couldn't. So
> to support your argument, you should be in favor of the commit. not
> against.
Ok, then post the request you are sending. The whole request must be a
valid HTTP/1.1 request with a properly delimited body, rather than just
a HTTP header, followed by random data.
This is not a valid request, for example:
GET /foo HTTP/1.1
Host: bla
my content (wait 10 s) more of my content
>> I fail to see what your purpose is to step on my toes like this, and
>> barge in with commit, when you didn't discuss anything.
> not sure what your toes and the ASF owned repository have in common ;)
To give an example: I suppose I could try committing random stuff to the
clustering module.
> We're discussing it now, you started it with a veto, and yes, i could
> have used the endless discussion tactic to prove the bug, but it was
> faster to come in with a solution.
That's what you are doing right now, rather than convince me that you
understand all the issues.
Ok, I'm going to bed now, and then on WE. I hate it when people force me
to stay up until 2AM on friday just because I made the mistake of
checking my email before going to bed ...
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat Comet Model
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> all, I have made a little image that would explain the idea I have
>> (and implemented today) for the Tomcat model, would like to get some
>> feedback,
>>
>> Remy and I already have an open dialogue, but its subjected under a
>> commit, so if you didn't read that one, this one has a nice pix
>> also available at http://www.halosg.com/Comet.png
>>
>> this doesn't break the original Comet model, it is backwards
>> compatible, yet it extends a little bit further making it more useful
>> for no latency lagging
>
> There is no difference at all, this is still Comet (yes, you can get
> two read events in a row).
and that is the exact bug I fixed. Before the commit, you couldn't. So
to support your argument, you should be in favor of the commit. not against.
>
>
> I fail to see what your purpose is to step on my toes like this, and
> barge in with commit, when you didn't discuss anything.
not sure what your toes and the ASF owned repository have in common ;)
We're discussing it now, you started it with a veto, and yes, i could
have used the endless discussion tactic to prove the bug, but it was
faster to come in with a solution.
> Similarly, the endless discussion tactic that I've seen you use in the
> past is also very evil. Is it a bit of pay back because you resent
> some of my earlier positions ?
No resentment here, I have high respect for you, we all have our
personal quirks.
>
> Rémy
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat Comet Model
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> all, I have made a little image that would explain the idea I have (and
> implemented today) for the Tomcat model, would like to get some feedback,
>
> Remy and I already have an open dialogue, but its subjected under a
> commit, so if you didn't read that one, this one has a nice pix
> also available at http://www.halosg.com/Comet.png
>
> this doesn't break the original Comet model, it is backwards compatible,
> yet it extends a little bit further making it more useful for no latency
> lagging
There is no difference at all, this is still Comet (yes, you can get two
read events in a row).
I fail to see what your purpose is to step on my toes like this, and
barge in with commit, when you didn't discuss anything. Similarly, the
endless discussion tactic that I've seen you use in the past is also
very evil. Is it a bit of pay back because you resent some of my earlier
positions ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org