- From: David Morris <dwm@xpasc.com>
- Date: Wed, 26 Mar 2008 21:07:01 -0800 (PST)
- cc: HTTP Working Group <ietf-http-wg@w3.org>
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 Thursday, 27 March 2008 05:07:46 UTC