W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2007

Re: protocol support for intercepting proxies

From: Adrien de Croy <adrien@qbik.com>
Date: Tue, 19 Jun 2007 11:31:21 +1200
Message-ID: <467715C9.7020202@qbik.com>
To: Henrik Nordstrom <henrik@henriknordstrom.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>



Henrik Nordstrom wrote:
> mån 2007-06-18 klockan 15:55 +1200 skrev Adrien de Croy:
>> I'm talking about intercepting proxies, which squid is not.
>
> Isn't it? That's news to me an the countless number of network admins
> which uses it that way... (supported since 1998).
>
sorry - my mistake.  You'd know :)

I was assuming that squid didn't have packet interception capabilities, 
and that therefore couldn't itself intercept TCP connections. 

But even if it doesn't, I guess the interception part can be provided by 
some other device.

>> Many clients (esp SMB) don't have any tech support staff, or their staff 
>> are not very knowledgeable.
>
> True, and they generally either install something prepackaged for them
> with support, or have someone make the initial setup for them..
>
> What exactly is the use case here? A network admin not knowing how their
> network knows, installing a proxy, and not having any documentation on
> the network requirements of installing a proxy? And expecting it to just
> work without making any network changes?

actually yes.  Insane though it may seem.  Or even no network admin at all.

Any amount of documentation of any quality doesn't make admins read it.

Hotels are a classic case.  You should see the hoops companies like 
Cisco jump through to get hotel guests access through a hotel gateway 
without a human anywhere having to do anything (i.e. work whether or not 
DHCP enabled on the guest laptop by using ARP spoofing and VLANs, work 
whatever subnet the client is on, and whatever the DNS and default 
gateway settings are).

Then try ringing the front desk when you can't get your laptop working.  
They are generally completely clueless. 

>
>> When it works sure it works.  When it doesn't there are a bunch of 
>> places to start looking, and that's where the support cost comes in.
>
> So there is an opportunity for you to write a support tool telling the
> customer why their WPAD setup fails.. and while at it add tests for some
> of the other common network misconfigurations..
Sure that's an option.  Actually one we've considered many times.

But in my experience, users are really lazy.  It's a bit of a sad 
indictment on net protocols in general that we still have the problems 
that we do, from ARP, DHCP, IP routing upwards.  The protocols are so 
old, but the people using them now are

a) less informed
b) less kindly towards being confronted with having to actually *learn* 
something

Anything that can be reliably automated is a help.

It's all very well explaining to people that if they wanted to fly a 
helicopter, or perform brain surgery they would need to learn something 
(train even!).  When it comes to using software, people have an 
expectation that they should be able to do anything without having to 
learn a thing.  Educating people is expensive.  Even more so when they 
resist it.  Manuals and documentation are simply not read, and utilities 
are not used.  So the level of automation becomes a competitive factor.

Regards

Adrien

>
> Regards
> Henrik

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Monday, 18 June 2007 23:31:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:10 GMT