Hello, About 'reducing load considerably' i was just quoting text from the website, that's not my opinion.
And as dormando said, this is for a usecase really similar to mogilefs (by the way i discovered the reproxy feature with mogilefs). It is not to serve content like css/html or php generated content, it's for serving files like videos and photos. We don't want to expose the files directly and want a fine control on their access something that you can't really have with a 302, especially if your file servers only support basic Http with no support for rewrite or fancy features like checking a secure url or access token. And even with secure url, you can't control things like the number of time that a file can be downloaded by an authenticated user. With reproxy we can implement all these features inside the app server really easily. Sebastien Estienne On Sun, Sep 12, 2010 at 22:19, dormando <[email protected]> wrote: >> 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 >
