Re: 209 and SPDY

The http/2 push mechanism is largely intended as a "pre-caching" or
"cache-update" optimization. The intent is to allow a server to
preemptively push cacheable resources it expects to be requested. Such
preemptive responses must be associated with an initial request and are not
end to end. In other words, it's perfectly legal for an intermediary to
block the push from propagating out to the client device. It is not
expected that client developers will expose any particular API for
accessing pushed resources. Rather, implementations will use those pushed
resources to prepopulate responses, such that when the get request is sent
by the client, it can be quickly served by the cache.

- James
On Mar 21, 2014 1:34 PM, "henry.story@bblfish.net" <henry.story@bblfish.net>
wrote:

>
> On 21 Mar 2014, at 20:50, Eric Prud'hommeaux <eric@w3.org> wrote:
>
> On Mar 21, 2014 8:38 PM, "henry.story@bblfish.net" <
> henry.story@bblfish.net> wrote:
> >
> > During the last conf call the 209 issues were discussed.
> >
> >     http://www.w3.org/2013/meeting/ldp/2014-03-17#209
> >
> > The logs don't make it clear who was speaking, and a lot of the
> arguments seem to be missing.
> > I understood that it was Erik Wilde who was reporting back form the
> London IETF meeting.
> > He reported back that one pushback ( from whome ? ) was that SPDY or
> HTTP2 allowed the
> > server to send back responses to documents that had not been requested
> by the client, and
> > that this could solve the 209 problem. Essentially the server could just
> send back a document
> > ( but only from the same server ) that was the one requested, without
> the client asking for
> > it. This seemed interesting, but it would be nice to have a link to the
> passage in the RFC
> > for where this is specified.
> >
> >   It seemes odd to me that this feature could be generally made available
> > without requiring the server to keep a lot of state about the client and
> what it had received.
> > For example if we looka at all the 303s used by the foaf ontology, every
> foaf term redirects
> > to the ontology document. The server would have to keep track of each
> client to know
> > that it had allready received the document, before sending it again.
> That seems odd.
>
> It may be odd for SPDY in general, but less so for our use case. Recall
> that all we really hope to achieve with 209 is to reduce from two round
> trips to one, even at the cost of a potential cache miss for multiple
> redirects to the same resource. Any even partially effective cache
> "prediction" in SPDY would only be of benefit to us.
>
> I can see that it could be beneficial, but the question above I raised
> should lead us to look more carefully at the
> SPDY specification. As I had understood SPDY is generally semantically
> equivalent to HTTP1.1 just with a lot of optimisations
> built in. So this is feature of pushing before being asked is new to me,
> and before agreeing that a 209 is not what we need
> some more information would be welcome.
>
> Henry
>
>
> >   Henry
> >
> >
> > Social Web Architect
> > http://bblfish.net/
> >
> >
>
>
> Social Web Architect
> http://bblfish.net/
>
>