Push API: not a friend of SPDY

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, 27 October 2014 14:56:05 UTC