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