Hi guys, sorry for not responding earlier.
On Mon, Dec 23, 2013 at 11:02:34PM +0100, Lukas Tribus wrote: > > To be more clear: > > There is "client side", which is client to haproxy. > > And there is "server side", which is haproxy to server. > > > > My patch implement mark for "server side", while > > http-request/http-response as i see in source code only for "client > > side". > > Yes, I see. > > > Currently, the features set-mark and set-tos need to be set with the > http-request/http-response command. This can be confusing and the result > is indeed not always what one would expect or desire (even though the > documentation is not wrong). > > Regardless whether we set "set-mark" or "set-tos" in the frontend or the > backend, in http-request or http-response, the setsockopt() call is always > about the frontend HTTP session only - the only difference being that the > frontend acts before the backend and http-request acts before http-response. Indeed that's a good point. > We can't: > - influence the backend HTTP session > - influence traffic when we are not intercepting HTTP (TCP mode) > - influence the first packet (if we route backend traffic differently based > on tos/mark, the first SYN may already need correct tos/nfmark marking, > otherwise it may be forwarded on the wrong interface and subsequently > dropped) > > > Imho the features set-mark and set-tos, and possibly also set-nice need > to be moved from the http-request/response layer out to the main layer of > configuration, where we have things like block and redirect, so that > we can: > > - combine them with ACLs > - make them work in TCP mode > - implement them to work with backend TCP sessions > - allow set-tos/set-mark to take effect before the SYN packet leaves the box > > > While your patch fixes your particular use case, Denys, I think we should > try the improve the whole situation. I agree with your points. I know that William has already started to factor out all the tcp/http actions but that's a tedious work. In an ideal world, we should be able to merge almost all of them. > Willy, was there a specific use-case when you implement those features? Any > thoughts about this? Yes, the purpose was precisely to affect traffic to the client depending on the request. For example, a non-authenticated visitor might use a different QoS setting or even be routed via a different link. I'm not using these features myself and I don't even remember whom I discussed with before implementing them given they were trivial. I would have no problem with starting to rename them (remember we're still in -dev) so that they're set-frontend-mark, set-frontend-tos or whatever shorter form we could imagine, then propagate them to TCP rules and finally have the same set for the other side. Regards, Willy
