Hi,
> 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. 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. Willy, was there a specific use-case when you implement those features? Any thoughts about this? Regards, Lukas
