You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Michael Osipov <mi...@apache.org> on 2019/10/11 12:21:09 UTC
Possible bug in Http11Processor/SocketWrapperBase
Folks,
while working on BZ-63835 I have noticed an odd thing and I'd like
someone to review whether my code/understanding is wrong or the one
already present in Tomcat.
Note: The same code path in HTTPd behaves corectly.
Consider this output received by curl:
> HTTP/1.1 302
>
> Transfer-Encoding: chunked
> Keep-Alive: timeout=300, max=100
> Connection: keep-alive
>
> HTTP/1.1 302
>
> Transfer-Encoding: chunked
> Keep-Alive: timeout=300, max=99
> Connection: keep-alive
>
> HTTP/1.1 302
>
> ...
>
> HTTP/1.1 302
>
> Transfer-Encoding: chunked
> Keep-Alive: timeout=300, max=2
> Connection: keep-alive
>
> HTTP/1.1 302
>
> Transfer-Encoding: chunked
> Connection: close
we have a total of 100 requests (HTTP/1.1 302). I'd assume the
connection to sustain 100 requests and on the n+1 requests to be closed.
This is caused by
> } else if (maxKeepAliveRequests > 0 &&
> socketWrapper.decrementKeepAlive() <= 0) {
> keepAlive = false;
> }
while decrementKeepAlive() being a predecrement, chopping off the
current request.
Making this postdecrement the outcome is as expected:
> HTTP/1.1 302
>
> Transfer-Encoding: chunked
> Keep-Alive: timeout=20, max=100
> Connection: keep-alive
>
> HTTP/1.1 302
>
> Transfer-Encoding: chunked
> Keep-Alive: timeout=20, max=99
> Connection: keep-alive
>
> ...
>
> HTTP/1.1 302
>
> Transfer-Encoding: chunked
> Keep-Alive: timeout=20, max=2
> Connection: keep-alive
>
> HTTP/1.1 302
>
> Transfer-Encoding: chunked
> Keep-Alive: timeout=20, max=1
> Connection: keep-alive
>
> HTTP/1.1 302
>
> Transfer-Encoding: chunked
> Connection: close
having 101 requests in total, matching HTTPd behavior.
The expired header proposal says:
> The value of the "max" parameter counts the number of requests since
> the connection was created.
My code is here:
https://github.com/apache/tomcat/commit/a5e3e1d7a498a3156350ae8bbed36706b2600e64
Am I wrong?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Possible bug in Http11Processor/SocketWrapperBase
Posted by Michael Osipov <mi...@apache.org>.
Am 2019-10-11 um 17:06 schrieb Mark Thomas:
> On 11/10/2019 13:21, Michael Osipov wrote:
>> Folks,
>>
>> while working on BZ-63835 I have noticed an odd thing and I'd like
>> someone to review whether my code/understanding is wrong or the one
>> already present in Tomcat.
>
> <snip/>
>
>> we have a total of 100 requests (HTTP/1.1 302).
>
> That is consistent with the docs that state there will be
> maxKeepAliveRequests before the connection is closed.
>
>> I'd assume the
>> connection to sustain 100 requests and on the n+1 requests to be closed.
>
> That assumption is not consistent with the documentation (which has been
> the same for as long as I can remember).
I have just reread the documentation in Tomcat and in HTTPd. They both
sound similiar, but why are both differntly implemented? Would you say
that bouth have a different intepretation and neither is wrong?
I tend to agree with your that if 100 is send 100 is max, and not 100 + 1.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Possible bug in Http11Processor/SocketWrapperBase
Posted by Mark Thomas <ma...@apache.org>.
On 11/10/2019 13:21, Michael Osipov wrote:
> Folks,
>
> while working on BZ-63835 I have noticed an odd thing and I'd like
> someone to review whether my code/understanding is wrong or the one
> already present in Tomcat.
<snip/>
> we have a total of 100 requests (HTTP/1.1 302).
That is consistent with the docs that state there will be
maxKeepAliveRequests before the connection is closed.
> I'd assume the
> connection to sustain 100 requests and on the n+1 requests to be closed.
That assumption is not consistent with the documentation (which has been
the same for as long as I can remember).
> The expired header proposal says:
>> The value of the "max" parameter counts the number of requests since
>> the connection was created.
The same proposal also states that the use of the max parameter is
deprecated.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org