Re: Push API: not a friend of SPDY

Follow-up: there was an issue for meta-data already on the Github.

https://github.com/w3c/push-api/issues/81

Please, think of the resources and be webby to one another.
Cheerio,
rektide

On Mon, Oct 27, 2014 at 10:55:40AM -0400, rektide@voodoowarez.com wrote:
> Hello. I heard Push is finally in consideration, and having a link put in front of me finally got around to
> looking- while I'm overjoyed to think the user-agent might expose endpoints, this implementation is however not
> a friend to SPDY (nor a friend to HTTP); comments, 2:
> 
> 
> SPDY has push. I'd like to see a Push API that can inform the serviceworker of data pushed via SPDY push. No
> endpoint registration is required! It's a capability which already exists in every SPDY connection, for which
> the browser has no corresponding ability to detect the Push. Push already exists, we just don't signal it.
> 
> Exposing an HTTP server that works as an ingestion endpoint is awesome, it's far more flexible, and far less
> tightly coupled. This absolutely needs to be another, available form of Push for the user-agent; 100%.
> 
> But I'd also like to be able to use the push channel that already exists. Please allow SPDY Push to work as a
> transport in to Push API.
> 
> 
> Second, why is no header information available in the Push message? Making the client a server but then putting
> masking tape over the envelope is... un-ethical, brutal, mean, dispirited, breaks things heniously. People are
> going to send HTTP traffic to it anyways, they're just going to have to wrap/pack unwrap/unpack it, possibly
> through someone's reverse proxy. For frell sake, expose the headers. The data is going to get there, this is
> what _is_ going to happen, don't make it a sin of different horrible ways of munging it together.
> 
> That means you need a little bit more well formed an object for Push message; one that looks like an HTTP
> request. Might I recommend picking the most harmonious, sensible existing spec out there, such that things
> generally work rather than making a brand new IDL for Request?  The dead-obvious no-effort-required
> everything-plays-nice developers-don't-laugh-at-you/hate-you-forever options would be to implement (as closely
> as permittable) the existing spec for an http request-
> https://fetch.spec.whatwg.org/#request-class
> 
> 
> I'd point to two previous projects of mine I'd hope Push could help me fully deprecate & close the book on-
> Pipe Layer, a bidirectional asynchronous http over http project, doing an Opera Unite like thing to reverse
> proxy requests received on the server to the browser)
> https://github.com/rektide/pipe-layer
> Pushchannel, which tracks SPDY Push messages and sends X-Associated-Content messages in reply to real resource
> requests, thereby signalling the user-agent as to the existence of the pushed resources,
> https://github.com/rektide/pushchannel
> 
> Alas, if someone wants to push http traffic to ServiceWorker, they'll ahve to pack their messages, often times
> meaning reverse-proxying through a packing service to achieve interop. WAMP ho, and that's effing horrible crufty
> ugly dumb and unnecessary.
> 
> Alas #2, SPDY's push still doesn't signal and is still all but useless as a push mechanism.
> 
> 
> Whether you will this or you wont, still yours,
> rektide
>

Received on Monday, 3 November 2014 19:17:50 UTC