> Am 28.04.2016 um 10:08 schrieb Rainer Jung <rainer.j...@kippdata.de>:
> 
> Am 28.04.2016 um 04:30 schrieb William A Rowe Jr:
>> On Wed, Apr 27, 2016 at 6:16 PM, Yann Ylavic <ylavic....@gmail.com
>> <mailto:ylavic....@gmail.com>> wrote:
>> 
>>    I was offline today so couldn't comment on the different messages on
>>    the subject, so I'll try to summarize (here) my understanding, so
>>    far...
>> 
>>    On Wed, Apr 27, 2016 at 8:41 PM,  <wr...@apache.org
>>    <mailto:wr...@apache.org>> wrote:
>>    > Author: wrowe
>>    > Date: Wed Apr 27 18:41:49 2016
>>    > New Revision: 1741310
>>    >
>>    > URL:http://svn.apache.org/viewvc?rev=1741310&view=rev
>>    > Log:
>>    >
>>    >   Ensure http2 follows http in the meaning of
>>    >   status WRITE (meaning 'in the request processing
>>    >   phase' even if still consuming the request body,
>>    >   not literally in a 'now writing' state).
>> 
>>    This is indeed consistent with how we report http1 state currently,
>>    but maybe it could be more intuitive to report READ until the body is
>>    consumed in http1 rather than changing http2?
>>    Unless we want to minimize scoreboard updates, for performance
>>    reasons...
>> 
>> 
>> Well, we always want to be considerate of performance.
>> 
>> That said, we absolutely must not change the semantic meanings of
>> the server-status results on the maintenance branch.  Change those
>> meanings on trunk for a future 2.6/3.0?  Sure... but 2.4.x needs to
>> behave as 2.4.x has behaved from the start.
> 
> I agree we shouldn't change the semantics of R/W during 2.4. People might 
> monitor the numbers of R and W and will be quite surprised by seeing a 
> noticeable shift from W to R.
> 
> I think it would be a good change for 2.6/3.0 to make R including reading the 
> request body and only after having read it switch to W. We can mention it in 
> CHANGES / migration guide and personally I think those semantics would be 
> more intuitive.

That is how I understood it to be when I made the status updates in mod_http2. 
But it should of course be in line how we report the http/1.x scores.

Reply via email to