On 3 June 2013 23:19, Ali Majdzadeh <ali.majdza...@gmail.com> wrote: > > Thomas, Jonathan > Thanks for your responses. Well, the problem I currently face, supposing that > I am using the correct terminology, is how to maintain a failed HTTP request; > (For example, a file download request). Do you aware of any solutions > regarding this issue?
You'll need to write code. Either client-side or server-side (in the middle, in front of HAProxy), you'll need to solve part of this in code. However ... > What is your suggested plan in order to achieve such a solution? ... I suggest you don't. Sincerely. Don't bother solving this problem, would be my strong professional suggestion, until a cost/benefit analysis from The Business demonstrates that you have to. And if there /isn't/ such an analysis -- if you're just up against morons who spout "failure is not an option; 100% uptime is essential" without showing /why/ it's essential -- then your problem isn't a technical problem; it's a person problem :-) Here's a very simplified rationale for this: as you write down the list of moving parts that /could/ fail during a single download, you will eventually come to the conclusion that solving the problem for each of those parts *when*they*are*in*an*exceptional*situation* would take hugely more engineering effort than lost sales will cost you. Well, probably. I don't know what you're actually serving over HTTP, of course :-) > Does HAProxy help in this context? It can do, due to its extremely configurable health checks. If you've committed to solving this problem entirely, however, it will need more than just HAProxy. That's the sort of situation into which I normally step wearing my "consultant" hat, however, and charge you money ;-) Jonathan -- Jonathan Matthews // Oxford, London, UK http://www.jpluscplusm.com/contact.html
