Re: PROPOSAL: i76 Use Proxy

I also agree on deprecation, but we actually went so far as to implement 
it, which is where I found out that no browsers support it (which is why 
I agree it should be deprecated).

Our use case was

client on LAN not configured to use proxy, connects out through a 
gateway with an intercepting proxy on it.  Proxy detects that connection 
was intercepted, and sends back a 305 to get the client to make a direct 
proxy connection, thereby solving certain issues with intercepted 
connections (specifically issues related to authentication and caching).

I disagree with others that the security issues in such a use-case can't 
be adequately dealt with, but IMO the point is now moot anyway since 
it's unlikely sufficient incentive could be found for browser authors to 
implement it, especially when there are other available options such as 
WPAD etc.

Regards

Adrien


Josh Cohen (MIG) wrote:
> I agree on deprecation.
>
> Regarding the question about this feature's purpose...
> I must confess that at the time, I was an advocate in the WG of these features.
> The use cases from my memory, while never clearly defined, were oriented around perf, load balancing and security.
> An application could instruct clients to access it through a proxy in order to have that proxy do various caching or balancing.
>
> Similarly, for certain network sources (eg mobile), the app could redirect the client to a proxy that could do something special for a mobile device, or secure the traffic.  "ah, you are coming from ATT mobile, you must use their outbound proxy which has a secure connection to us"
>
> I suspect there was also interest in client browser configuration for proxy settings given the activity going on at the time.  Some other related efforts were ICP (proxy mesh routing protocol), CARP ( client side proxy hashing ) , javascript configuration files, and WPAD (web proxy autodiscovery).
>
> Today, the common solution to that is WPAD + javascript.
>
>
> -----Original Message-----
> From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org] On Behalf Of David Morris
> Sent: Wednesday, March 26, 2008 10:07 PM
> To: ietf-http-wg@w3.org
> Cc: HTTP Working Group
> Subject: Re: PROPOSAL: i76 Use Proxy
>
>
>
> I agree ... deprecate it ... I still don't see a use case as to why
> I'd want to specify a single use proxy as a application designer.
>
> When were were doing 1.0 and 1.1, I expected it was supposed to be a
> way to configure a user agent to use a proxy for every thing... For
> example, a fire wall might intercept all attempts to use HTTP directly and
> provide the proxy. But that wasn't what was defined ... so it makes no
> sense to me.
>
> Dave Morris
>
>
> On Tue, 25 Mar 2008, Henrik Nordstrom wrote:
>
>   
>> On Tue, 2008-03-25 at 14:30 +0100, Julian Reschke wrote:
>>     
>>> Henrik Nordstrom wrote:
>>>       
>>>> ...
>>>> I am fine with deprecating 305 as "never implemented", moving it's
>>>> definition to an appendix explaining the differences between 2616 and
>>>> 2616bis.
>>>> ...
>>>>         
>>> :-)
>>>
>>> That's what I was trying to do.
>>>
>>> Do you want to propose concrete text?
>>>       
>> I can try, but not sure the result is the best.
>>
>> Key points to include in priority order if anyone wants to try:
>>
>>  - Commonly not implemented
>>  - Not obvious how it was meant to be implemented. Hop-by-hop or
>> end-to-end?
>>  - If hop-by-hop then it can't be used for clients using an HTTP/1.0
>> proxy or HTTP/1.1 proxy not implementing 305.
>>  - If end-to-end then it can't be used for clients using a proxy as HTTP
>> has no provision of clients requesting a chained proxy request.
>>  - Same functionality can almost be emulated using a 302/307 redirect to
>> another request-URI acting as application level proxy for the resource,
>> with the only noticeable difference being the request-URI (has mainly
>> implications on relative references from the resulting resource).
>>
>> Regards
>> Henrik
>>
>>     
>
>
>
>   

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

Received on Wednesday, 2 April 2008 01:19:04 UTC