[SR-Users] Via header, branch parameter and syn_branch

[Henning Westerholt]

Am Donnerstag, 23. Mai 2013, 11:12:20 schrieb Richard Brady:
> The syn_branch global parameter results in the use of a "synonym"
> branch parameter in the Via header for statelessly forwarded requests
> as a performance optimisation.
> 
> This was originally done by setting branch=0 which, while not strictly
> compliant with 3261 (8.1.1.7 and 16.6 item 8), would not cause any
> problems with a downstream proxy or UA compliant to either 3261 or
> 2543 since it does not contain the cookie and is therefore
> self-evidently not guaranteed to be unique.
> 
> Then a patch was added (commit ebb3b08) to change it from branch=0 to
> branch=z9hG4bKcydzigwkX which includes the cookie, thus declaring
> itself to be unique when it clearly is not.
> 
> This takes the optimisation too far as it deliberately misleads
> downstream proxies with regard to the uniqueness of the parameter and
> breaks the mechanism in 17.2.3 for identifying unreliable (non-unique)
> branch parameters for transaction matching which should then fall back
> to header inspection but does not. The result is that unrelated
> requests can be identified as duplicates of each other.
> 
> Also note 3261 section 16.11 on Stateless Proxy behaviour: "The
> requirement for unique branch IDs across space and time applies to
> stateless proxies as well."
> 
> Has the commit above introduced a bug and should it be reverted?
> 
> And should the next major release have a default of syn_branch=0?
> Since with syn_branch=1 the branch=0 version has been known to cause
> interop issues in the past (see below) and I can confirm the
> branch=z9hG4bKcydzigwkX version causes interop issues in the present.

Hello Richard,

syn_branch=0 should be made the default, this is what we use as default since 
years in our backend. The performance concerns that were the reason for 
introducing it long ago are nowadays not valid anymore (even on embedded 
systems).

I would suggest to remove this parameter completely, one less if/else case in 
the module code and also a a parameter less to document and learn for our 
users.

Henning