[sr-dev] personal summary of what still needs to be done
Andrei Pelinescu-Onciul
andrei at iptel.org
Tue Sep 22 01:11:31 CEST 2009
On Sep 21, 2009 at 21:34, I?aki Baz Castillo <ibc at aliax.net> wrote:
[...]
>
> > BTW here are other possible differences in reply handling:
> >
> > - received 503 triggers dns failover. If 503 is the final reply, it's
> > replaced with a 500. Also if the blst_503 parameter is on (default
> > off), the source of the 503 reply is blacklisted (using the value
> > in the Retry-After header if present and the blst_503 def_timeout,
> > min_timeout and max_timeout parameters).
> > - if the final reply is 401 or 407, all the www & proxy auth. headers
> > from all the 401 & 407 replies received on all the branches are
> > aggregated into the final reply (can be turned off with
> > aggregate_challenges).
>
> Doesn't SR's TM module implement these features?
It does, what's listed are differences in reply handling from ser 0.9.x.
I don't know what k does, so I listed them just in case someone needs a
different behviour and we need another switch for turning something off
(the default behaviour is rfc conformant, but so is the 6xx handling
:-)).
>
>
> > - reply priority (negative reply that wins):
> > 6xx
> > 3xx
> > 4xx
> > 5xx
> >
> > 4xx priority: 401, 407, 415, 420, 484 and then the rest (ascending
> > order of their number)
> >
> > With the exception of 4xx, all other replies in the same class, are
> > sorted according to their number (e.g. 501 wins over 502).
>
> I think it's the correct order.
Andrei
More information about the sr-dev
mailing list