Re: HTTP2 Expression of Interest : Squid

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.

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.

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

- James


Best regards, Julian
>
>
>
>
>
>