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

RE: PROPOSAL: i76 Use Proxy

From: Josh Cohen (MIG) <joshco@windows.microsoft.com>
Date: Tue, 1 Apr 2008 16:54:35 -0700
To: David Morris <dwm@xpasc.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <55982DAC95C5454197DB9912D48B3E1D02C6665666@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>

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
>
Received on Tuesday, 1 April 2008 23:56:00 GMT

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