Subject: #179: Relax Via MUST

From: Mark Nottingham <[email-masked]>
Date: Mon, 13 Jul 2009 15:59:13 +1000

Catching up on a very old discussion:
   http://trac.tools.ietf.org/wg/httpbis/trac/ticket/179
Currently, intermediaries MUST add the Via header;

The Via general-header field MUST be used by gateways and proxies to  
indicate the intermediate protocols and recipients between the user  
agent and the server on requests, and between the origin server and  
the client on responses.

This doesn't reflect current practice.

When making this decision, it's worth noting that some HTTP mechanisms  
operate differently when a message sender knows that the entire path  
is HTTP/1.1, and the primary way of discovering this is the Via header.

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

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 17 Jul 2009 01:53:49 +0200

> This doesn't reflect current practice.

But I don't see much need for action. Via is slowly gaining acceptance.

> is HTTP/1.1, and the primary way of discovering this is the Via header.

Correct.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 17 Jul 2009 10:13:58 +1000

I'm fine closing this with no action; IIRC the previous discussion was  
leaning towards removing the requirement.

Others?

Cheers,

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 16 Jul 2009 19:44:32 -0700

On Jul 16, 2009, at 5:13 PM, Mark Nottingham wrote:

> I'm fine closing this with no action; IIRC the previous discussion  
> was leaning towards removing the requirement.
>
> Others?

There is no way we can remove the requirement without removing
half a dozen other features.  Intermediaries that don't send
Via are broken and will continue to be broken even if the
requirement doesn't exist.

....Roy

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 17 Jul 2009 18:40:41 +1200

I think it might have been me that raised this issue a while back

I agree it needs to be closed with no action.

Taking it out breaks too much stuff.

The original query related to customers who have unreasonable ISPs who 
don't want customers to run proxies to get more use out of their link, 
these customers didn't want there to be anything in their HTTP requests 
that would give away the existence of a proxy.

I think this case is probably best handled with an option (default off) 
to make the proxy "stealthy", which strictly speaking makes it broken 
(no outbound Via).  Inbound Via is another matter and doesn't have any 
privacy issues.

It's probably even less of an issue now with the prevalence of proxies 
for other purposes, even running on the local machine (e.g. some 
filtering / AV software installs a proxy for localhost).

Thanks

Adrien

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 17 Jul 2009 16:49:28 +1000

In the back of my head, I've actually been thinking it would be useful  
to note that Via is necessary for operation of some protocol features,  
which is why there's the option for a minimal Via header, e.g. "1.1  
foo".

I say this because I suspect that many implementers just don't realise  
that it has these uses. Of course, you're not going to dissuade the  
more paranoid folks from stripping anything that looks like  
intermediation, but oh well.

Cheers,

On 17/07/2009, at 4:40 PM, Adrien de Croy wrote:

> The original query related to customers who have unreasonable ISPs  
> who don't want customers to run proxies to get more use out of their  
> link, these customers didn't want there to be anything in their HTTP  
> requests that would give away the existence of a proxy.
>
> I think this case is probably best handled with an option (default  
> off) to make the proxy "stealthy", which strictly speaking makes it  
> broken (no outbound Via).  Inbound Via is another matter and doesn't  
> have any privacy issues.
>
> It's probably even less of an issue now with the prevalence of  
> proxies for other purposes, even running on the local machine (e.g.  
> some filtering / AV software installs a proxy for localhost).
>
> Thanks
>
> Adrien
>
>
> Roy T. Fielding wrote:

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 17 Jul 2009 19:05:19 +1200

yes, I think many specific-application proxies don't put Via in, 
probably for that reason.

in fact I think many proxies also mirror the HTTP version they received 
in the request through to the next hop.

Transparent proxies are still required to insert Via?

Mark Nottingham wrote:
> which is why there's the option for a minimal Via header, e.g. "1.1 foo".
>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 17 Jul 2009 17:04:42 +1000

On 17/07/2009, at 5:05 PM, Adrien de Croy wrote:

> in fact I think many proxies also mirror the HTTP version they  
> received in the request through to the next hop.

Yes, that probably could use some emphasis as well.

> Transparent proxies are still required to insert Via?

If you mean intercepting, yes (although they're not really kosher,  
it's still necessary for them to do this if the various protocol  
features that depend upon it are going to function).

>
> Mark Nottingham wrote:
>> In the back of my head, I've actually been thinking it would be  
>> useful to note that Via is necessary for operation of some protocol  
>> features, which is why there's the option for a minimal Via header,  
>> e.g. "1.1 foo".
>>
>> I say this because I suspect that many implementers just don't  
>> realise that it has these uses. Of course, you're not going to  
>> dissuade the more paranoid folks from stripping anything that looks  
>> like intermediation, but oh well.
>>
>> Cheers,
>>
>>
>>> who don't want customers to run proxies to get more use out of  
>>> their link, these customers didn't want there to be anything in  
>>> their HTTP requests that would give away the existence of a proxy.
>>>
>>> off) to make the proxy "stealthy", which strictly speaking makes  
>>> it broken (no outbound Via).  Inbound Via is another matter and  
>>> doesn't have any privacy issues.
>>>
>>> proxies for other purposes, even running on the local machine  
>>> (e.g. some filtering / AV software installs a proxy for localhost).
>>>
>>> Thanks
>>>
>>> Adrien
>>>
>>>
>>> Roy T. Fielding wrote:
>>>>> I'm fine closing this with no action; IIRC the previous  
>>>>> discussion was leaning towards removing the requirement.
>>>>>
>>>>> Others?
>>>>

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 17 Jul 2009 19:15:31 +1200

> features that depend upon it are going to function).

I meant the definition in RFC2616

"A "transparent proxy" is a proxy that does not modify the request or 
response beyond what is required for proxy authentication and 
identification"

But intercepting proxies are another kettle of fish again.

I think the para at the start defining proxy states that unless there's 
wording specifically relating to requirements for transparent or 
non-transparent proxies, then the wording applies to both.

Which then answers my question, since there's no mention of transparent 
or non-transparent in the clause for Via, one should assume it applies 
to both, which means a transparent proxy must also insert Via, which 
then leaves one wondering about the definition of it (unless we consider 
that Via is a function of identification?)

Cheers

Adrien

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 17 Jul 2009 17:17:15 +1000

There are *no* unique requirements placed upon semantically  
transparent proxies in 2616, which is why they were removed in -05;  
more than anything, they were just a device to explain the motivation  
behind the design decisions in HTTP caching (and IMO it was a fuzzy  
way to do it).

Cheers,

On 17/07/2009, at 5:15 PM, Adrien de Croy wrote:

> "A "transparent proxy" is a proxy that does not modify the request  
> or response beyond what is required for proxy authentication and  
> identification"
>
> I think the para at the start defining proxy states that unless  
> there's wording specifically relating to requirements for  
> transparent or non-transparent proxies, then the wording applies to  
> both.
>
> Which then answers my question, since there's no mention of  
> transparent or non-transparent in the clause for Via, one should  
> assume it applies to both, which means a transparent proxy must also  
> insert Via, which then leaves one wondering about the definition of  
> it (unless we consider that Via is a function of identification?)
>
> Cheers
>
> Adrien
>
>
> --

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 17 Jul 2009 10:02:41 +0200

> Transparent proxies are still required to insert Via?

Intercepting proxies does not exists in the HTTP specifications, and
there is things which need to be done differently in such setups.

But Via is not one of them. A intercepting proxy which do not insert Via
will break things just the same ways as a normal proxy or intermediary
so yes it MUST insert Via.

A semantically transparent proxy is just a proxy, and MUST insert Via.

Regards
Henrik

---

From: Adrien de Croy <[email-masked]>
Date: Sat, 18 Jul 2009 00:01:12 +1200

> Yes, that probably could use some emphasis as well.

httpbis-p2-messaging-07 has the following text in s 3.1

"Due to interoperability problems with HTTP/1.0 proxies discovered since 
the publication of [RFC2068], caching proxies MUST, gateways MAY, and 
tunnels MUST NOT upgrade the request to the highest version they support. "

gateways cover scenarios such as a reverse proxy
tunnels seems to refer to tunnelling via CONNECT (or even just a dumb 
mapping)

what about non-caching proxies?  Is it intended that only caching 
proxies have the must requirement, or should this apply to all proxies?

Section 2.4 looks ambitious!!! is that what I think it is?  Intercepting 
the TCP connection?  Even though WinGate does it, and clients want it, 
we recommend against it.  It does horrible things to auth.

Regards

Adrien

>>>> broken (no outbound Via).  Inbound Via is another matter and

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 17 Jul 2009 13:12:16 +0100

> A semantically transparent proxy is just a proxy, and MUST insert Via.

What does omitting Via break, if the intercepting proxy does not
change the messages, only filters them (and replaces responses with
errors in the case where something is blocked)?

Or even if they rewrite URLs and/or edit the content of responses, if
they don't do any caching?

Which reminds me.

I've seen intercepting proxies used by a few ISPs on port 80,
presumably to reduce their upstream bandwidth costs.  They are very
annoying because they tend to be down from time to time and there's no
easy way to bypass them.  (When it happens, I run a real proxy on a
server in a data centre, and configure my browser to use that.
Something other people generally can't do).

I think the ISPs' intercepting proxies I've seen as a mixture of
adding Via and not adding Via.

Intercepting proxies may also be used for censorship.  Such proxies try
to be hidden, so they're unlikely to insert Via.

-- Jamie

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 17 Jul 2009 14:26:03 +0200

> errors in the case where something is blocked)?

Omitting Via breaks path HTTP version capability detection.

Normally you don't need to care about the version support of the whole
forwarding path, but sometimes you do.

> adding Via and not adding Via.

Indeed. For various reasons most of which completely unrelated to
interception, but some like to try to hide their proxy for various dumb
reasons..

> to be hidden, so they're unlikely to insert Via.

Indeed.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 17 Jul 2009 14:28:34 +0200

> we recommend against it.  It does horrible things to auth.

Which section where? Thereis no 2.4 in p2-semantics, at least not the
version I read..

Regards
Henrik

---

From: Adrien de Croy <[email-masked]>
Date: Sat, 18 Jul 2009 00:33:48 +1200

I think mandating that the proxy always sends the version it supports 
breaks things that Via is the fix for. I don't propose changing that 
requirement though.

For interest though, there's also the rule about combining contiguous 
via tags if the protocol version is the same, and the entities are under 
the same administrative control. 

Therefore in terms of the arguments about breaking protocol features by 
omitting Via, that only actually happens in the request-side if the 
request received by the proxy isn't the same protocol version as the 
proxy sends.

Since for example if both are HTTP/1.1, then the proxy adding a Via: 1.1 
Gateway header doesn't give any more information in terms of protocol 
capability of the request path.

the same logic would follow for the response path if the version sent by 
the proxy were the same as received from upstream.

Adrien

---

From: Adrien de Croy <[email-masked]>
Date: Sat, 18 Jul 2009 00:35:47 +1200

sorry, that was a typo.  p1-messaging, not p2-messaging.

http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p1-messaging-07.txt 
page 14

Adrien

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 17 Jul 2009 14:34:57 +0200

> we recommend against it.  It does horrible things to auth.

Found it i thing.. p1 2.4 

Yes that is about intercepting the TCP connection. But still unclear to
me what the section is to say other than mentioning that such technique
has been deployed. Not sure the specifications should define a profile
for those (or to be precise I think not).

There is a fair bit of things in the specs which isn't worded with port
80 interception in mind, and the implications of that is best left
outside the spec imho as things start to get very muddled if we try to
account for this use case even if commonly deployed today.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 Jul 2009 13:11:41 +1000

Looking at the current text, it's pretty self-explanatory; while there  
might be some editorial tweaks that could make it more apparent, the  
motivation really is already there.

Closing with no action; if the editors want to pick it up as editorial  
and tweak for clarity, please do so.