- From: Wesley Oliver <wesley.olis@gmail.com>
- Date: Fri, 29 Jul 2016 08:35:22 +0200
- To: Lucas Pardue <Lucas.Pardue@bbc.co.uk>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Adrien de Croy <adrien@qbik.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>
- Message-ID: <CACvHZ2a_Ltczh6FtEDHvYg_vAK17RvyZ4TT0xE974YPR4CPkqw@mail.gmail.com>
Hi,
After taking into account some of your replies to summaries this is were I
believe this is going.
Typically headers can be deferred as stated, however, the concern about
proxies
may potentially be valid. What I am wanting wouldn't matter as proxies
would have to update themselves to support this modification just they
would have had
to updated them selves to support http 2.0.
Yes one could delay the output of the response header status code,
but unfortunately if their is an error in the page or last minute change
then the data frame/response body would still be stale and not reflect the
new page and status code.
Using a header continuation frame could be used as a hack, if the browser
implementation allowed,
which is an alternative to the javascript page redirect while pushing
content on another stream, as I proposed in
the document below:
https://docs.google.com/document/d/1xGY4GycBMt4zyCoJpzoIZrlLOs1bwaRVBfPE9aXdbyE/edit?usp=sharing
How many browser support the concept of processing more a response body with
more than one <html> page section where the last one wins.
https://www.w3.org/TR/html5/semantics.html#semantics Refer to sections -
4.1 The root element.
I envisage the following work flow.
Request
Response Headers - for current request
Data Frame - Requested pages.
Response Headers - Continuation - output 404, Currently the body is
incorrect for the new status page and a new data frame would need to
be transmitted.
DataFrame - 404 header, but the browser wouldn't understand this and would
currently treat this as the same respsonse body, problem.
Concept on how I envisage the modified http 2.0 state to work.
Request
Response Headers - for the current request.
Data Frame - Requested pages.
Optimistically send ENDHEADERS ,STARTHEADERS with the
Response Headers - Output 404 and because this is not a continuation
headers frame, it reset the stream state implicitly as it is the first
headers frame.
The browser also then knows to reset its
internal workings such that it can render a new response body for the same
url.
Data Frame - Start, to mark difference between old header response body and
the new header response body.
End Stream.
I still believe that the http 2.0 streaming and multiplexing life cycle
changes need to be supported
it make this behavior less hacky and more concrete as if it was support.
Does any one differ in their understanding.
What would the next steps be for this concept in moving it forward into
an offical request.
Kind Regards,
Wesley Oliver
In message <em51dddd7f-de76-4e87-abcb-0f315b115499@bodybag>, "Adrien de
Croy" w
rites:
>The problem with deferring headers in responses to after content, is=20
>that proxies often make policy decisions based on response headers, and=20
>therefore need these to be all up front.
>
>Trailers for this reason are also a problem
We talked about this in the workshop, and yes, trailers *in general*
is a problem, but the specific trailers people care about are not.
The trailers people ask for, as far as I understood:
Etag
Set-cookie
Cache-Control(/Expires/Age)
They are *not* a problem.
---------------------------------------------------------------
The problem with deferring headers in responses to after content, is that
proxies often make policy decisions based on response headers, and
therefore need these to be all up front.
Trailers for this reason are also a problem
Adrien
-------------------------------------------------------------
On Wed, Jul 27, 2016 at 3:33 PM, Lucas Pardue <Lucas.Pardue@bbc.co.uk>
wrote:
> Hi,
>
>
>
> HTTP/2 does not use the status line, instead it defines the :status
> pseudo-header field the MUST be included in a response. This carries the
> status code only.
>
>
>
> With chunked transfer encoding you could return a HEADERS with 200 status
> and END_HEADERS set, start sending body bytes across multiple DATA frames,
> and finish by signalling completion with a final HEADERS with END_HEADERS
> and END_STREAM set (this is the HTTP Trailer). The browser should process
> the body bytes as it receives them i.e. adding data to the DOM.
>
>
>
> This method should in theory work equally well for dynamically generated
> pushed resources. The server should multiplex all of the frames across the
> connection.
>
>
>
> In the failure case, when an error occurs you could add a custom header
> field to indicate the nature of the failure (e.g.
> http://engineering.pivotal.io/post/http-trailers/).
>
>
>
> Your initial proposal sounds like a modification/extension of HTTP
> semantics (RFC 7540 section 5.5.), in HTTP/2 that MUST require a
> negotiation before being used. The negotiation could be implemented via
> exchange of SETTINGS frames, but that is going to introduce addition
> round-trips and probably negate some of the benefit of reducing latency.
>
>
>
> Lucas
>
>
>
> *From:* Wesley Oliver [mailto:wesley.olis@gmail.com]
> *Sent:* 27 July 2016 13:46
> *To:* Lucas Pardue <Lucas.Pardue@bbc.co.uk>
> *Subject:* Re: Concepts to improve Http2.0
>
>
>
> Hi,
>
>
>
> Yes I would like to push out dynamically generated content as soon as
> possible,
>
> weather the dynamically generated content originates from a push response
> or the current request response.
>
> The server would then alternate transmission between the dynamically
> generate push response or current request responses.
>
>
>
>
>
>
>
> It is not very clearly to me right now, given that http 2.0 is wrapping
> the existing protocol weather the newer
>
> http2.0 protocol will relax the strict requirement that the Status Line
> could be in a continuation frame as well
>
> as the Field Order of header sections.
>
>
>
> If you read the extracts from http1.1 below, their is more to this in the
> details of the headers.
>
>
>
> Ideally I would like to be optimistic and send a response with status of
> 200 and the dynamically generated message
>
> body sections as become available with out buffering, if something were to
> go wrong, then I would like to send a response that
>
> would override the current response message with a one such as a 403 or
> 308 status code.
>
>
>
> In the details of the headers section for http1.1 the browser wouldn't be
> able to display the page
>
> in the interim or possibly start passing the contents of the body as
> describe below.
>
> I would like for browser potentially in the future to be able to start
> passing the body.
>
> As you can see my very last diagram where I indicate the non-blocking
> behavior for the body,
>
> were it is immediately processed.
>
>
>
> As per the sections of *http1.1 in of *F*ield Order * below, more
> attention to the details may have to be looked at
>
> and recommendations on what would and wouldn't result in blocking the
> client side browser from starting the process
>
> the body/message before the final headers are received.
>
>
>
> If the browser is not able to processes the message/body as soon as
> possible, we may
>
> have improved bandwidth over the wire, however, their will still be an
> upfront render latency and the peak workload
>
> that is created(battery consumption). Were the processing of the message
> body could have been parsed and render in the mean time.
>
>
>
> I hope that this provides a bit more context to the level of optimization
> that I would like to have opened up.
>
>
>
> Kind Regards,
>
>
>
> Wesley Oliver
>
>
>
>
>
>
>
> Fielding & Reschke Standards Track [Page 7]
>
> ------------------------------
>
> <https://tools.ietf.org/html/rfc7230#page-8>
>
> RFC 7230 <https://tools.ietf.org/html/rfc7230> HTTP/1.1 Message Syntax and Routing June 2014
>
>
>
>
>
> A server responds to a client's request by sending one or more HTTP
>
> response messages, each beginning with a status line that includes
>
> the protocol version, a success or error code, and textual reason
>
> phrase (Section 3.1.2 <https://tools.ietf.org/html/rfc7230#section-3.1.2>), possibly followed by header fields containing
>
> server information, resource metadata, and representation metadata
>
> (Section 3.2 <https://tools.ietf.org/html/rfc7230#section-3.2>), an empty line to indicate the end of the header
>
> section, and finally a message body containing the payload body (if
>
> any, Section 3.3 <https://tools.ietf.org/html/rfc7230#section-3.3>).
>
>
>
>
> 3.1.2 <https://tools.ietf.org/html/rfc7230#section-3.1.2>. Status Line
>
>
>
>
>
> The first line of a response message is the status-line, consisting
>
> of the protocol version, a space (SP), the status code, another
>
> space, a possibly empty textual phrase describing the status code,
>
> and ending with CRLF.
>
>
>
> status-line = HTTP-version SP status-code SP reason-phrase CRLF
>
>
>
> The status-code element is a 3-digit integer code describing the
>
> result of the server's attempt to understand and satisfy the client's
>
> corresponding request. The rest of the response message is to be
>
> interpreted in light of the semantics defined for that status code.
>
> See Section 6 of [RFC7231] <https://tools.ietf.org/html/rfc7231#section-6> for information about the semantics of
>
> status codes, including the classes of status code (indicated by the
>
> first digit), the status codes defined by this specification,
>
> considerations for the definition of new status codes, and the IANA
>
> registry.
>
>
>
> status-code = 3DIGIT
>
>
>
> The reason-phrase element exists for the sole purpose of providing a
>
> textual description associated with the numeric status code, mostly
>
> out of deference to earlier Internet application protocols that were
>
> more frequently used with interactive text clients. A client SHOULD
>
> ignore the reason-phrase content.
>
>
>
> reason-phrase = *( HTAB / SP / VCHAR / obs-text )
>
>
> 3.2.2 <https://tools.ietf.org/html/rfc7230#section-3.2.2>. Field Order
>
>
>
>
>
> * The order in which header fields with differing field names are*
>
> * received is not significant. However, it is good practice to send*
>
> * header fields that contain control data first, such as Host on*
>
> * requests and Date on responses, so that implementations can decide*
>
> * when not to handle a message as early as possible. A server MUST NOT*
>
> * apply a request to the target resource until the entire request*
>
>
>
>
>
>
>
> *Fielding & Reschke Standards Track [Page 23]*
>
> ------------------------------
>
> <https://tools.ietf.org/html/rfc7230#page-24>
>
> *RFC 7230* <https://tools.ietf.org/html/rfc7230>* HTTP/1.1 Message Syntax and Routing June 2014*
>
>
>
>
>
> * header section is received, since later header fields might include*
>
> * conditionals, authentication credentials, or deliberately misleading*
>
> * duplicate header fields that would impact request processing.*
>
>
>
> A sender MUST NOT generate multiple header fields with the same field
>
> name in a message unless either the entire field value for that
>
> header field is defined as a comma-separated list [i.e., #(values)]
>
> or the header field is a well-known exception (as noted below).
>
>
>
> A recipient MAY combine multiple header fields with the same field
>
> name into one "field-name: field-value" pair, without changing the
>
> semantics of the message, by appending each subsequent field value to
>
> the combined field value in order, separated by a comma. The order
>
> in which header fields with the same field name are received is
>
> therefore significant to the interpretation of the combined field
>
> value; a proxy MUST NOT change the order of these field values when
>
> forwarding a message.
>
>
>
>
>
>
>
> On Wed, Jul 27, 2016 at 12:21 PM, 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.
>
> ---------------------
>
>
>
>
>
> --
>
> --
> 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
Received on Friday, 29 July 2016 06:35:53 UTC