Ah, great, thanks. I'd like to configure the dispatch order in the proxy. The apps don't know about each other, all they know is whether they service a particular uri (in which case they return http 200 + body content) or not (return http 404). Further, as java apps, they're deployed to a "context"- say, /x- and all want to be deployed to that same context (because they all handle a variety of paths under that context).
To use X-Accel-Redirect it looks like I'd need to: * deploy the apps to internal paths /x1, /x2, /x3, but trick them into thinking they're all deployed to /x (think I can do this with header tricks in the proxy) * change the apps not to deliver a 404 when they can't service a particular uri; instead they would need to deliver a 200 with the X-Accel-Redirect header pointing to the next internal path. IOW, each app would need to know what internal path it's deployed to and what app is next in the chain. That may be doable- but what I'd like is to be able to list the apps in the proxy config: /x => [ http://localhost:11111/x, http://localhost:11112/x, http://localhost:11113/x, http://localhost:11114/x ] and have the proxy manage visiting each in order, returning the first non-404. On Wed, Jun 9, 2010 at 11:55 AM, Rapsey <[email protected]> wrote: > I use it to dispatch to another app. As for ordering, I think you would need > to do it from the app if I understand your use case correctly. > > > Sergej > > On Wed, Jun 9, 2010 at 5:38 PM, Jonah Benton <[email protected]> wrote: >> >> Thanks for the rapid response. At first blush, X-Accel-Redirect >> doesn't look to be quite what I need: >> >> * it appears that the specific use case is to dispatch to optimized >> static file delivery; it's not clear whether the >> dispatched-to-back-end can be another app, rather than something that >> can be delivered with sendfile() >> * assuming the dispatched-to-backend can be another app, can apps >> arbitrarily chain themselves together with a series of >> X-Accel-Redirect responses, or does nginx impose some sort of limit >> * if apps can arbitrarily chain themselves together, this still means >> I need to maintain the app ordering in the webapp rather than in the >> proxy. The webapps are java, so this will be a little tricky, and the >> chaining appears to have to be by path, which would be proxy-only >> knowledge. >> >> So, maybe it's doable, though I'd rather be able to just maintain the >> ordering in the proxy configuration. >> >> I'll look some more, though, thank you for the pointer. >> >> On Wed, Jun 9, 2010 at 2:58 AM, Rapsey <[email protected]> wrote: >> > You can't do this with haproxy, but you can with nginx and >> > X-Accel-Redirect >> > >> > >> > Sergej >> > >> > On Wed, Jun 9, 2010 at 5:17 AM, Jonah Benton <[email protected]> wrote: >> >> >> >> Greetings, >> >> >> >> I have several web applications that each service different portions >> >> of the same taxonomy. The taxonomy is very deep- millions of >> >> resources- and the rules that dictate which part of the taxonomy each >> >> application serves are fluid and changing. In general it isn't easy to >> >> determine declaratively which web application should service which >> >> uri. >> >> >> >> I'd like to set up a proxy dispatch hierarchy, such that requests >> >> arriving at a proxy front end would be dispatched to one of the web >> >> applications. The response from web application 1 would checked by the >> >> proxy front end. If it's a 404, then the front end discards the >> >> response from web application 1, and dispatches to the next web >> >> application. If non-404, then the response is returned to the client >> >> and the transaction is considered handled. A 404 response from the >> >> last web application would be considered a true 404 and would get >> >> returned to the client. >> >> >> >> From a quick look at the configuration, it doesn't appear that this >> >> can be done with HAProxy (nor with any other proxy software I've >> >> looked at). Am I wrong, can this be arranged? >> >> >> >> Please cc me, I'm not subscribed to the list. >> >> >> >> Thank you, >> >> >> >> Jonah >> >> >> > >> > > >
