Re: HTTP2 Expression of Interest : Squid

On Tue, Jul 17, 2012 at 10:55 AM, James M Snell <jasnell@gmail.com> wrote:

>
>
> On Tue, Jul 17, 2012 at 10:17 AM, Julian Reschke <julian.reschke@gmx.de>wrote:
>
>> On 2012-07-17 19:02, Gabriel Montenegro wrote:
>>
>>> From: Adrien de Croy [mailto:adrien@qbik.com]
>>>>
>>> ...
>>>
>>>> I agree, and actually I'd be keen to apply this philosphy in both
>>>> directions,
>>>> where no significant resource is transmitted in either direction
>>>> without the
>>>> recipient indicating prior willingness (either by requesting it, or
>>>> indicating
>>>> willingness).  What I'm getting at here is large POST / PUT requests.
>>>>  Currently
>>>> it's a mess esp with auth in the mix.
>>>>
>>>
>>> Along these lines, to help with a  POST/PUT with auth in the mix we
>>> mentioned an idea in our authentication EoI of a lightweight probe:
>>>
>>> http://lists.w3.org/Archives/**Public/ietf-http-wg/**
>>> 2012JulSep/0239.html<http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0239.html>
>>> :
>>>
>>> 1.       Lightweight "probe" for POSTs and PUTs.  Initial PUTs and POSTs
>>> with long entity bodies will cause problems because of the extra round trip
>>> required by authentication. ("Initial" means when first request on a
>>> connection is PUT or POST). If the body is indefinite length, it may not be
>>> able to be recreated. This is a problem with any multi-legged
>>> authentication scheme in HTTP. It could be avoided if there were a
>>> guaranteed benign request type that could be used to force authentication
>>> if needed before doing the PUT or POST.
>>>
>>
>> We have
>>
>>   Expect: 100-continue
>>
>> for that, no?
>>
>>
> Heh... I suggested that yesterday and was told that I was being silly.
>
>
You've roughly described the first server push that we played with! :)

The problems we found with this:
1) Often servers will begin sending data before they've computed the
dynamic bit. As a result, you'll need to be able to mention at any time,
that you're going to promise to push something. You can't assume you'll
know the entire list of resources at any point until the request is done,
and you'll wanting to be stuffing bits into the pipe before that happens if
there is dead air.
2) You'll want to promise a push without bloating the fetch latency for the
requested resource. This means that you'll want to send as little as is
possible to identify to the browser what is to be pushed, and after the
main resource has been sent, then begin pushing the rest.
3) Sometimes, you'll want to change your mind. You were pushing a number of
images that the user is going to use, but you discovered that they need
some essential javascript instead. You should be able to interrupt the
lower priority data with the higher priority data so that you soften or
eliminate the effect of non-optimal mentions or ordering of resources in
the page.
4) For some content, sending the first N bytes with a higher priority than
the rest of the resource results in a usable page far sooner. This is very
interesting for many .jpgs and similar resources that can refine as more
data is pushed.

I've been kicking around the idea of a new PUSH* method whose semantics,
> quite literally, are: Here's a bag of bits I want to send you. (*My
> instinct is that POST could work just as well). The PUSH would consist
> initially of a HEADERS frame containing a basic manifest of the content the
> sender wishes to send... Once the manifest is sent, the send sends each bit
> of content preceded by a HEADERS frame that provides the detail of the
> content... essentially a form of multipart entity that uses HEADERS and
> DATA frames for delineation. The HEADERS frame for each piece of content
> would provide information such as ETag, Last-Modified, Content-Location,
> Content-Type and Cache-control for each individual piece of content
> delivered. If the recipient determines that it either already has a
> particular piece of content or doesn't want it for whatever reason, the
> recipient has the option of canceling out of the stream at any time.
>
> Example.. sender wants to push two items... recipient oks the transfer ...
> note that the sender doesn't have to wait for the SYN_REPLY to begin
> sending the data...
>
> => SYN_STREAM (:method=PUSH)
> => HEADERS (
>      Content:[
>        (Content-Location: ..., ETag: ...),
>        (Content-Location: ....,ETag: ...)
>    )
>
> <= SYN_REPLY (:status: OK)
>
> => HEADERS (
>      Content-Location: ...,
>      Content-Type: ...,
>      ETag: ....,
>      Last-Modified: ....)
>
> => DATA
> => DATA
> => DATA
>
> => HEADERS (
>      Content-Location: ...,
>      Content-Type: ...,
>      ETag: ....,
>      Last-Modified: ....)
>
> => DATA
> => DATA
> => DATA (fin)
>
> <= DATA (fin)
>
> This approach work in both directions... e.g. server-push and client-push
> (uploading files). It also provides the recipient with enough additional
> information to handle caching, and gives the recipient the opportunity to
> tell the sender no. To be useful, the manifest would need to have enough
> useful information to allow the recipient to determine if it needs the
> content or not (e.g. is the same version already cached?).
>
> Yes, this adds significant complexity to the problem so I'm not sure if
> this strategy would work or not but I'm experimenting with it at least.
>

cool!


>
> Server push is good, but the client needs to be allowed to opt out at any
> time.
>

Why?
-=R


>
> - James
>
>
> Best regards, Julian
>>
>>
>>
>>
>>
>>
>