sw-delta
sw-delta copied to clipboard
gmetais
RFC 3229 Compliance
Hi there! I stumbled upon your delta encoding implementation for browsers when creating my own service worker and Express plugin.
Have you looked at the RFC 3299 draft for delta encoding? It's old, and still hasn't gone past the draft stage, but it may work as a standard so that implementations can work together.
Hi William,
I didn't know about this draft, thank you! I wonder why it's never made its way to the HTTP protocol, because it was a great idea.
However, what I don't like about this proposal, is that the URL is not modified. It works by adding some new HTTP headers and by using a the 226 status code. I might be wrong, but this could be a problem with some proxies.
@gmetais HTTPS avoids that problem, and service workers already require HTTPS.
Just to clarify, RFC 3229 is not a draft, it is an accepted standard as every other IETF standard is.
@joshtriplett The problem would be about your own caching proxies such as nginx or a CDN in front of your servers. They do read the requests, than convert to HTTPS.
They're very good at caching resources based on urls. I'm not an expert, but configuring them to understand the 226 status code + the headers would be more difficult (and introduce a risk with IE and its "Vary-Header" problem).
Hmm.. I'm pretty sure IE will never support ServiceWorker so there is no reason to send anything special in header for it.
They do read the requests, than convert to HTTPS.
What does this mean? Isn't request already in HTTPS in ServiceWorker world?
@NekR A caching proxy is not something that bothers us, it's something very useful and quite common on large websites. It's an equipment between the server and the browser that improves performances of the platform.
As you said, a proxy is not allowed to intercept requests if the browser and the server talk to each other over HTTPS. So the common solution is:
HTTPS HTTP
Browser <------------> Caching proxy <-----------> Server
As I wrote in the README, you should use some kind of caching proxy along with sw-delta because the server-side computation is very slow. So I repeat, the proxy is not a problem that we are looking to avoid. It's an equipment that we need to use.
More about caching proxies: https://en.wikipedia.org/wiki/Proxy_server#Improving_performance
As you said, a proxy is not allowed to intercept requests
I wasn't saying this or wasn't saying proxies are problems, you said that. I just asked why you mention HTTP and why proxies do so. Thanks for answering to it, but I still don't see how that could be a problem. Proxy converts HTTP request to HTTPS, but how that affects outer world? There cannot be other proxies between your server and your proxy, the only place where there could be additional proxies is between your proxy and the browser, e.g. airport's/hotel's proxy.
As I wrote in the README, you should use some kind of caching proxy along with sw-delta because the server-side computation is very slow.
Shouldn't server-side delta caching be an implementation detail of the server plugin? Ideally, you can tune the server, specifying how aggressive you want to keep deltas. I don't see why you'd need a proxy layer.
SDCH is also relevant here, although only implemented in Chrome and It's derivatives (Opera)
http://caniuse.com/#feat=sdch
but how that affects outer world?
@NekR You are right, it doesn't affect the outer world. I'm only talking about the pain of configuring the proxies that are parts of your architecture.
Shouldn't server-side delta caching be an implementation detail of the server plugin?
Yes, the caching could absolutely be done server-side too. But (at least in the case of NodeJS), I don't think the server-side package should include caching. It should remain as simple as possible to allow users to choose the best option for their platform (memory caching, filesystem caching, proxy...).
Maybe we could add an example of server-side caching that wraps sw-delta-nodejs.
SDCH is also relevant here, although only implemented in Chrome and It's derivatives (Opera)
Can you tell us more about it? How can it help? Is it a way to reduce the file size, or is it a way to be more compliant with RFC 3229?
@gmetais This LinkedIn article does the concept justice much more than I could.
Basically, SDCH compresses the content with a dictionary (hence the DC) and uses the VCDIFF RFC3284. Essentially, on subsequent requests, you're only downloading the changes, which sounds very similar to what you're doing here.
I'm only talking about the pain of configuring the proxies that are parts of your architecture.
I see, yeah, this makes sense.
Just to clarify, RFC 3229 is not a draft, it is an accepted standard as every other IETF standard is.
It's only a proposed standard. It says that in the link you posted, and also here https://tools.ietf.org/html/rfc3229
