Re: Internal Redirection & License

On Tue, Feb 26, 2008 at 3:33 PM, Willy Tarreau <w#1wt.eu> wrote:

> 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 :-)

Ah - so problem solved. Don't have to worry about a partial HTTP Response leaking back to the client.

,<snip>

>
> 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 think this is something that should be the problem of the app developers ( i.e. me!) to deal with. Ultimately, I'd say that we have to accept that RequestA to DynamicServer is mapped entirely and is replaced by URI-X which is what gets passed back in the DynamicServer's Response X-Accel-Redirect header and it is up to DynamicServer to make this semantically correct by encoding whatever parameters it needs in the URI-X so that the Response from StaticServer becomes a legitimate and meaningful response to RequestA (even though StaticServer probably never sees RequestA). Some of the varients like bytes-range are either gonna be unsupported our would require haproxy to lend some assistance by allowing the addition of special Response headers. Would be an advanced capability and I'm not fully up on its viability for you.

So I guess I'm asking haproxy to drop my DynamicServer Response and simply return back StaticServer's response. StaticServer should probably be responsible for making its own Response headers look like they came from DynamicServer in terms of "host" header. "accept-encoding" must be realized by DynamicServer - it either routes to a URI-X that provides that specific accept-encoding or it returns the proper HTTP error result. Perhaps have haproxy make a regex that matches a certain pattern in Response headers to be turned into Request headers. X-bytes-range-Redirect gets translated to the bytes-range header value in the URI-X Request to the StaticServer for example. But that's an advanced optional feature that I'd happy wait til a future release for. ;)

For now I'm thrilled to replace the DynamicServer's Response with StaticServer's Response for the original Request to DynamicServer. The rest becomes the application's responsibility to work out. That alone's going to give me dramatic horizontal scalability & flexibilty for my key capacity issues. It's a specialized feature for a specialized problem and I don't expect it to be a general solution to all things. I'm a software development guy so I don't always know what's possible/easy/best way to deal with network infrastructure issues so I defer to your experience in that regard.

Make sense? Notice I start off saying its my problem then propose a solution for you to handle it for me? :)

   Thanx much,

• Ben