W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2014

Re: Push API: not a friend of SPDY

From: <rektide@voodoowarez.com>
Date: Mon, 3 Nov 2014 14:17:27 -0500
To: public-webapps@w3.org
Message-ID: <20141103191727.GH17066@voodoowarez.com>
Follow-up: there was an issue for meta-data already on the Github.


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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:32 UTC