Re: p1: Via and gateways

OK, it seems like we agree we can relax the MUST generate Via on responses from gateways, provided that they don't removing any existing Via header. 

I'll mark this for -23.


On 24/04/2013, at 4:38 PM, Willy Tarreau <w@1wt.eu> wrote:

> On Wed, Apr 24, 2013 at 01:27:45PM +1000, Mark Nottingham wrote:
>> 
>> On 23/04/2013, at 4:43 PM, Willy Tarreau <w@1wt.eu> wrote:
>> 
>>> Then I would propose this addition :
>>> 
>>>  Multiple Via field values represent each proxy or gateway that has
>>>  forwarded the message.  Each recipient MUST append its information
>>>  such that the end result is ordered according to the sequence of
>>> -  forwarding applications.
>>> +  forwarding applications. A gateway MAY simply relay any existing Via
>>> +  header field if it does not change the HTTP version, but it MUST NOT
>>> +  remove it.
>> 
>> This is already covered further down:
>> 
>>> A proxy or gateway may combine an ordered subsequence of Via header field
>>> entries into a single such entry if the entries have identical
>>> received-protocol values.
> 
> I don't read it exactly the same way, but probably it achieves the same in
> the end.
> 
>> The question I was raising was specific: can we relax the requirement for a
>> gateway to add Via to responses if there isn't already one present?
> 
> I think yes, we can relax it, as if there was none, then it means the
> gateway has not changed the connection's behaviour and the next hop just
> assumes the connection comes from the client. Again, in my understanding,
> Via is used to understand what transformation was operated on the path
> and what capabilities are offered. If the gateway does not change anything,
> Via offers no value except detecting loops. And since most gateways simply
> forward to the configured next hop, the risk of loop is not caused by
> external environment (eg: DNS) but by the configuration so it's not a
> problem.
> 
> But if we do so, we must specify that a gateway MUST NOT remove the
> Via header field in any case, otherwise it will break the loop detection
> mechanism of some other components.
> 
> Regards,
> Willy
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 8 May 2013 02:16:06 UTC