For what little it's worth: After having read this thread, I think the ./well-known/hints hack is the most sensible solution here.
Sure, we could put something in DNS, in HTTP headers, or in the main page's <head>. But the former two are beyond the technical abilities of most webmasters, and the latter arrives later than we want. (Also, I don't think DNS should contain HTTP hints; DNS is totally the wrong layer. And using a new HTTP header imposes a cost on every request, instead of on the first access to a given subdomain.) ./well-known/hints is a hack, but doesn't seem so bad to me compared to the alternatives. On Thu, Jul 12, 2012 at 9:52 AM, Justin Lebar <[email protected]> wrote: > 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
