Historically, we used the internal peer proxy as stream target, because
then we only cared about initiating a basic tcp connection with the
endpoint, and relying on parent proxy settings was enough.
But later, we introduced the possibility to connect to an SSL peer by
taking server's SSL parameters into acount. This was done in commit
1055e687 ("MINOR: peers: Make outgoing connection to SSL/TLS peers work.")
However, the above commit introduced an ambiguity:
peer_session_target() function was introduced, and the function will
either return the peers proxy's object or the current server's object
depending if ssl is configured or not.
While this works fine to ensure proper SSL handling while being
conservative with historical behavior, this cause other server transport
related settings to only work when ssl settings are provided, which is
quite debatable.
Indeed, while we're there, why not always using the server's object as
a stream target, to ensure all transport related options are properly
handled? Moreover, the peers documentation tells this:
... "support for all "server" parameters found in 5.2 paragraph that
are related to transport settings" ...
To remove the ambiguity and fully comply with the documentation, we make
peer_session_target() always return the server's object.
void peers_register_keywords(struct peers_kw_list *pkwl);
#if defined(USE_OPENSSL)
-static inline enum obj_type *peer_session_target(struct peer *p, struct stream *s)
-{
- if (p->srv->use_ssl)
- return &p->srv->obj_type;
- else
- return &s->be->obj_type;
-}
-
static inline struct xprt_ops *peer_xprt(struct peer *p)
{
return p->srv->use_ssl ? xprt_get(XPRT_SSL) : xprt_get(XPRT_RAW);
#else
static inline enum obj_type *peer_session_target(struct peer *p, struct stream *s)
{
- return &s->be->obj_type;
+ return &p->srv->obj_type;
}
static inline struct xprt_ops *peer_xprt(struct peer *p)