Re: Internal Redirection & License

Hi Benjamin,

On Tue, Feb 26, 2008 at 02:29:49PM +0700, Benjamin Scherrey wrote:
> Hi Willy,
>
> Thanx for the reply and please forgive my ignorance as I don't yet have
> experience with haproxy. So I'm gathering from your response that haproxy
> tries to move traffic on a per-packet basis therefore making switching
> choices based on http layer more complicated? Appreciate any insight into
> the design policy that impacts this. Kinda makes sense as being necessary
> for high capacity.

No, it's quite the opposite instead. It is reliable because it works at the session level and not at the packet level :-)

> Given the context of the above caveat, I'm wondering if it still isn't a
> reasonable option as it has nothing to do with the request at all but the
> response. haproxy gets a FileDownload request and sends it along to
> DynamicServer which peforms some AuthN/AuthZ & feature workflow stuff.
> Finally the ultimate GET request to the DynamicServer arrives but it doesn't
> actually hold the static file. It knows the name of the file on StaticServer
> so it actually creates a Response identical to what it would make if it was
> serving the file, but instead of providing the chunked data, it inserts a
> X-Accel-Redirect header with the StaticServer/File URI as its parameter and
> returns this as the full Response to haproxy.
>
> Now haproxy just has to keep on the lookout for X-Accel-Redirect in the
> header section of the HTTP Response. It could even send out the partial
> Response headers up until that point although that complicates things later.
> When it encounters X-Accel-Redirect, it will probably drop the rest of the
> original DynamicServer Response (preferably ALL if nothing has been sent to
> client - have to think this through a bit...) and performs an HTTP GET on
> the StaticServer URI returning its response instead (with the contents of
> the requested file). So client machine appears to have gotten the file from
> the DynanicServer (or its logical name) and haproxy hasn't had to perform
> any actual store & forward services to provide this capability. Obviously
> we'd want X-Accel-Redirect to leverage any LB capabilities so we could have
> an array of StaticServers available to leverage but the StaticServers should
> NEVER be addressable via an HTTP Request and only HTTP Responses from the
> approved DynamicServer should be able to use X-Accel-Redirect against those
> machines.

I will just ask you what I already asked to another guy who asked for this, since it does not seem obvious: what headers should haproxy use when playing the second request ? Should they be forced by the configuration, or taken from the initial request ? The "host" header, the "bytes-range", "accept-encoding", "accept", "cache-control", etc... All of those are very important and cannot be trivially guessed, so I hope you can understand my concerns since all the people asking for such a feature cannot themselves propose a response to this question :-)

> I'm probably over explaining but it's because either you or I are a bit
> confused about what's the business functionality and the technical context.
> Most likely I. :)

Maybe at the end we'll agree on a solution :-)

Regards,
Willy Received on 2008/02/26 09:33