This is interesting... * Does the additional request for ./well-known/hints on every new connection to an origin have performance implications, for the client or the server? I thought that we didn't like the hardcoded favicon.ico hack, and this seems like the same kind of thing.
Can we somehow slipstream this data into an existing HTTP response? Small files are the bane of fast websites, and even though this file doesn't block the page, there's still a page-load-time cost to fetching it, inasmuch as we're not fetching something else at the time. And of course all sites would pay a price, regardless of whether they used this manifest. * It seems to me that much of this proposal is subsumed by SPDY. SPDY headers and cookies are compressed across the whole SPDY session, so omitting them doesn't buy us much, right? It seems that the options which aren't subsumed by SPDY are pconn-ip, connect-timeout, read-timeout, and maybe ip-balance. But all of these could be sent as HTTP/SPDY headers, right? Obviously HTTP will continue to exist for a long time on the Web, and where we can easily speed up HTTP connections, we should do so. But what is the value proposition here for "significant content providers" -- why wouldn't you go for the Actually Fast Thing, instead of the imitation? -Justin On Thu, Jul 12, 2012 at 9:06 AM, Patrick McManus <[email protected]> wrote: > All, > > I've been getting pings from some significant content providers > interested in participating in an experiment where servers could opt-in > via hints on uri masks to receiving some form of streamlined http > requests. We don't normally do these kinds of things (see below) because > they could cause compatibility or flexibility problems, but having the > server signal that's cool with them (along with the scope of that > decision and some rules around how long that hint lasts) resolves a lot > of those issues and can result in better networking performance. > > examples: > * no cookies for /images/* please > * minimal headers are fine (no accept-*) > * my server can handle large numbers of parallel connections (which btw > doesn't mean its always the right thing to do, but the server's voice is > impt) > * minimal user-agent header is fine (e.g. "user-agent: firefox:14.0") > * /images/ works with http pipelines really well (static, small, etc..) > etc.. > > There is a draft for one potential framework here: > http://tools.ietf.org/html/draft-nottingham-http-browser-hints-03 > > If you've got thoughts on why this would be a bad idea, or thoughts for > other knobs I'd love to hear them. please read the draft first, of > course. > > Also, my apologies for crossposting this if that kind of thing bothers > you. I reserve it for rare occasions I assure you. > > -Patrick > > > > > _______________________________________________ > dev-platform mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
