Re: Concepts to improve Http2.0

Hi,

Is the http 2.0 state protocol meant to have been kept simple enough
to low level layers to directly understand the protocol at packet possibly
frame level inspection.

Kind Regards,

Wesley Oliver

On Fri, Jul 29, 2016 at 1:49 PM, Wesley Oliver <wesley.olis@gmail.com>
wrote:

> Hi,
>
> Sorry I missed that interpretation from the following
> and the fact the life cycle state diagram didn't have that requirement in
> it.
>
> 5 <https://tools.ietf.org/html/rfc7540#section-5>.  Streams and Multiplexing
>
>
>
>   The order in which frames are sent on a stream is significant.
>       Recipients process frames in the order they are received.  In
>       particular, the order of HEADERS and DATA frames is semantically
>       significant.
>
>
> Sections:
>
> 6.5 <https://tools.ietf.org/html/rfc7540#section-6.5>.  SETTINGS
>
>
>    A SETTINGS frame MUST be sent by both endpoints at the start of a
>    connection and MAY be sent at any other time by either endpoint over
>    the lifetime of the connection.  Implementations MUST support all of
>    the parameters defined by this specification.
>
>
>
> So typically their would be no problem in just using the SETTINGS frame
> then,
> to communicate that this functionality is support by the receiving peer.
>
> I can see why the intermediate proxies would have a problem and would
> require a round trip.
> However, intermediate proxies can should be allowed to modify settings
> frames as the pass thought it,
> downgrading the response to what the intermediately supports, which means,
> their wouldn't need to be a round trip confirmation as the server would
> always
> know the highest supported settings.
>
> The client browser should support all previous downgraded settings values.
>
> This potentially may not fit with all existing settings, meaning we may
> require
> categorizing settings into classes or their behavior/side-affects. So that
> certain settings may
> be optimistically overridden by intermediaries.
>
> I will look into this a little later on which settings would be affected
> by an optimistic composition
> approach covered in sections *6.5.2 Defined Settings Parameters*
>
>
> Kind Regards,
>
> Wesley Oliver
>
>
>
> On Fri, Jul 29, 2016 at 1:13 PM, Wesley Oliver <wesley.olis@gmail.com>
> wrote:
>
>> Hi,
>>
>> As per the spesification I dont'
>> see any requirement that the SETTINGS Frame has to be transmitted first.
>>
>>
>> On Fri, Jul 29, 2016 at 10:58 AM, Cory Benfield <cory@lukasa.co.uk>
>> wrote:
>>
>>>
>>> On 29 Jul 2016, at 09:31, Wesley Oliver <wesley.olis@gmail.com> wrote:
>>>
>>> I see that the documentation say nothing about how the negotiation is to
>>> happen.
>>>
>>>
>>> In this case, a setting is necessary: a header field is not good enough.
>>> This is because this functionality requires that all entities on the
>>> connection (intermediaries too) understand the change this makes to the H2
>>> stream state machine. That works when transmitted on a SETTINGS frame
>>> because each hop of the connection that is actually participating in the H2
>>> connection needs to look at the SETTINGS frame and respond appropriately.
>>> Header fields, however, may be passed through to the endpoint, which leads
>>> to a situation where the client and server can both do this but the
>>> intermediary cannot, and the intermediary mangles or otherwise terminates
>>> the connection.
>>>
>>> Otherwise it would have to wait for the settings frame communication to
>>> have proceed first,
>>> which then introduce latency for client side and would result in the
>>> server having to block
>>> before it could response, clearly a degradation of performance.
>>>
>>>
>>> The server needs to do this anyway. The start of a HTTP/2 connection
>>> involves both parties sending SETTINGS frames. The server cannot receive
>>> the first HEADERS frame without having previously received a SETTINGS from
>>> the client that would be offering support for this functionality.
>>>
>>> Cory
>>>
>>>
>>
>>
>> --
>> --
>> Web Site that I have developed:
>> http://www.swimdynamics.co.za
>>
>>
>> Skype: wezley_oliver
>> MSN messenger: wesley.olis@gmail.com
>>
>
>
>
> --
> --
> Web Site that I have developed:
> http://www.swimdynamics.co.za
>
>
> Skype: wezley_oliver
> MSN messenger: wesley.olis@gmail.com
>



-- 
-- 
Web Site that I have developed:
http://www.swimdynamics.co.za


Skype: wezley_oliver
MSN messenger: wesley.olis@gmail.com