Re: Push API: not a friend of SPDY

On Mon, Oct 27, 2014 at 11:58:03PM -0700, Costin Manolache wrote:
> On Mon, Oct 27, 2014 at 11:20 AM, <rektide@voodoowarez.com> wrote:
> 
> > On Mon, Oct 27, 2014 at 09:28:41AM -0700, Martin Thomson wrote:
> > > On 27 October 2014 08:42,  <rektide@voodoowarez.com> wrote:
> > > > Anyone who wants to implement a transport can frame it as they please.
> > Building
> > > > a Push that throws away this information when the message is an HTTP
> > message
> > > > is something that the lightcone of humanity will hate you for for as
> > long as
> > > > it holds together. You really really really can not skimp on this
> > because you
> > > > happen to want other circumstances: if you are building a Push spec
> > for the web,
> > > > it needs to be able to recieve web-like requsts.
> > >
> > >
> > > That's a pretty strong assertion.  Can you provide any justification
> > > for that?  Any metadata you might want to carry can always be placed
> > > in a payload after all.
> >
> 
> Not really - the payload is supposed to be end-to-end encrypted, so the
> push server can't place anything
> in the payload.  The push server may want to indicate at least the
> (authenticated) source of the
> message (unless it operates as an open-relay :-).
> 
> AFAIK http://tools.ietf.org/html/draft-thomson-webpush-http2-00 uses HTTP/2
> for the UA to
> push server - which obviously includes the usual headers.  So not really
> sure what this thread is
>  about and why the headers would be just dropped in the JS API, I am
> assuming they
> will show up when a clean way to expose them is found ?

This is my concern. I'm concerned that Push API leaves no standard JS API
for pushed resources to be seen as resources. Unless Push API has an
affordance for exchanging resources, it becomes very very hard to use.

For example, a scenario: meatspace, a webapp where a short movie clip and
text is sent to everyone looking at a web page. A client would need to get
a text message and a video message pushed to it.

How does the client know the content-type of the movie clip sent to them?

At present, I see no means for the Push API to afford this information, even
though it was sent to the WebPush server.

Hence my assertion:
1. Headers and method should be optional fields on the Push event (relaying
   the vital web information- content-type &c)
2. For consistency data should be renamed body.

Thank you very much for writing Costin. I greatly appreciate you stating
your confusion, and doubly appreciate you asking questions.

Received on Tuesday, 28 October 2014 14:58:01 UTC