> Last, I don't agree with you on the fact that it would "help to reduce > load considerably". If you're talking about the application servers' > load, generating this header is equal to generating a redirect. If you're > talking about the file server's load, it does not change anything for it. > If you're talking about the load balancer, it still has to handle two > connections while the standard redirect could have saved one by making > use of layer4 load balancing for the file server. If you're talking about > the network, well, you're saving one short response (redirect) and one > short request, which are very small compared to the rest of the data, > but since you can't allow the client to cache, the whole data will have > to be completely retransferred every time the client wants it. > > As you can see, I can't even identify one positive aspect of this method, > only a lot of downsides and possible issues.
Actually this is how some file storage systems work, like our own MogileFS: http://code.google.com/p/mogilefs/wiki/ServingOverview The actual location of the file (and filename) are hidden so the distributed filestore may transparently manage the file, its copies, which copy to use when, etc. Without X-Reproxy-URL we'd have to fully hide the lookup and would lose a lot of the flexibility of using HTTP internally. Some enterprising folks expose the files directly and use 302's, most use internals, whatever they need to do to get the job done. Many petabytes of information via dozens of websites are served this way hundreds of thousands of times per second, so it's useful to someone ;) If haproxy supported it, we could probably easily hook it into mogilefs as a frontend. There're more extravagant plugins that obviate the need of the application end lookup for nginx/perlbal, but those aren't necessary to make mogilefs useful. -Dormando
