[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