Re: WGLC: draft-ietf-appsawg-http-forwarded-02.txt

Agreed.

In general, if the protocol allows all information to be forwarded across
the proxy, then there is less of a need for it to attempt to make itself
invisible to client and server, which I think creates a lot of the problems
associated with proxies.

This aligns well with the "trusted proxy" idea -- intermediary support
should be more explicit in the protocol spec to reduce the likelihood that
intermediaries will have to introduce hacks to deliver the necessary
functionality into the network.

Peter

On Sat, May 5, 2012 at 9:51 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 5/05/2012 8:15 a.m., Peter Lepeska wrote:
>
>> I can think of an enterprise use case but it's pretty contrived. WAN
>> optimizing appliances use the TCP option field to auto-negotiate optimized
>> connections when appliances are present in the data path. See
>> http://www.cisco.com/en/US/**docs/solutions/Enterprise/**
>> Data_Center/WAASDC11.html<http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/WAASDC11.html>.
>>
>>
>> Should there be an HTTP proxy in between those optimizing appliances, the
>> TCP option field would be lost along with the original client source IP
>> address and port. However, if this information was included in the HTTP GET
>> Headers then the functionality could in theory be preserved.
>>
>> I know it's a stretch.
>>
>>
> Not so much of a stretch. I have a client this week asking about how to
> relay TOS information from parent proxy through child proxy and use it on
> the outbound client link.
>
> At present we have to rely on the kernel sockets API to access TOS values,
> which is lacking on a lot of systems. Long term I think that is the better
> way to go anyway but in general the principle is one to consider.
>
> AYJ
>
>