Re: Concepts to improve Http2.0

Wesley,

You may be interested in the following document.

https://tools.ietf.org/html/draft-kazuho-h2-cache-digest-01
On Wed, Jul 27, 2016 at 6:27 AM Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:

> Hi Wesley,
>
>
>
> I had a look over your document.
>
>
>
> Is the crux of your problem statement that you want to send out
> dynamically generated content as early as possible? Could your problem be
> solved by the use of chunked transfer encoding and  Trailers [1]? In HTTP/2
> frame format, the simplest response would be a series of frames such as
> HEADERS, DATA, HEADERS (Trailers with END_STREAM flag). This is explained
> in more detail in RFC 7540 section 8.1 [2].
>
>
>
> In the examples included in your document there are multiple “Dependent
> Resources” that get pushed. Are these independent static resources that the
> dynamic generated content refers to?
>
>
>
> As far as my understanding goes the current protocol mechanisms should
> permit chunked transfer and push promises without needing to modify the
> stream life cycle. Pushed resources would sit in the client cache ready to
> be used by the dynamically generated content when it is received and
> parsed. In other words, you could achieve your proposed improvemed timing
> diagram with current mechanisms.
>
>
>
> Regards
>
> Lucas
>
>
>
> [1] https://tools.ietf.org/html/rfc7230#section-4.1.2
>
> [2] https://tools.ietf.org/html/rfc7540#section-8.1
>
>
>
>
>
> *From:* Wesley Oliver [mailto:wesley.olis@gmail.com]
> *Sent:* 27 July 2016 07:20
> *To:* ietf-http-wg@w3.org
> *Subject:* Concepts to improve Http2.0
>
>
>
> Hi,
>
>
>
> I am not new to the concept of the IETF, however, I have yet to make an
> offical submission.
>
>
>
> I would like to put forth a concept that can further improve the
> performance of http 2.0.
>
> I have a couple of other concepts as well regarding content expiry headers
> which would affect http 1.1.
>
> Additionally I would also like to look into concepts to prevent
> unnecessary push requests for content that is already cached by the
> browser. Since mobile bandwidth constraints, would be obviously benefit
> from not push content that is already cached.
>
>
>
> Full document on the concept can be found  at the link below and first
> abstract can be found to follow this email.
>
>
>
>
> https://docs.google.com/document/d/1xGY4GycBMt4zyCoJpzoIZrlLOs1bwaRVBfPE9aXdbyE/edit?usp=sharing
>
>
>
> If you could please advise as to the path to follow.
>
>
>
>
>
> Kind Regards,
>
>
>
> Wesley Oliver
> Http Response Stream - Optimistic approach for performance improvement and
> Snowball effect of Response Body Programming paradigm shift of benefits
>
> *Abstract*
>
>
>
> Traditionally in http 1.1 one is required to buffer an http response on
> the server side. If a change to the headers was to be made during the
> response somewhere during the page generation code, because headers are not
> allowed to be changed after the message-body has been transmitted. Changing
> these semantics by removing this constraint in http 2.0 will open the door
> to an http response programming paradigm shift in possibilities. Benefits,
> improved and optimal bandwidth utilization, reduce overall page render
> resource latency and potentially an increase in server page requests that
> can be processed.
> Concept:
>
> Allow multiple response to be sent over the wire for the same request,
> whereby the last response that has been transmitted over the wire, will
> form the official response that will be permanently rendered in the client
> browser.
>
>
>
> This is an optimistic approach, when the response will not change,
> therefore eliminating the need to buffer the response. As soon as network
> buffer has a full packet or has been forced flushed it can be transmitted
> over the wire, reducing the latency of the response experience by the
> client. Additionally it also allows for improved bandwidth utilization
> after the server has received the request, as it can immediately start
> sending response packets, reducing potentially wasted bandwidth during the
> time in which the response is being generated and then buffered before
> transmission.
>
>
>
>
>
>
>
>
>
> --
>
> --
> Web Site that I have developed:
> http://www.swimdynamics.co.za
>
>
> Skype: wezley_oliver
> MSN messenger: wesley.olis@gmail.com
>
>
>
> ----------------------------
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
> ---------------------
>