Subject: Re: PROPOSAL: i76 Use Proxy

From: Mark Nottingham <[email-masked]>
Date: Tue, 11 Mar 2008 15:39:23 +1100

No further discussion, so calling this closed.

On 28/02/2008, at 4:51 PM, Mark Nottingham wrote:

>
> <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/76>
>
> As discussed, the proposal for closing this issue is to deprecate  
> the method, leaving the text in-place in the spec.
>
> I've seen a number of people agree that this is the correct course  
> of action, and no-one has objected. I'll leave the issue open for  
> another week+; unless someone speaks up, we'll close as planned.
>
> Cheers,
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 11 Mar 2008 10:52:24 +0100

> No further discussion, so calling this closed.

So what exactly do we do here?

Currently we have:

"9.3.6 305 Use Proxy

The requested resource MUST be accessed through the proxy given by the 
Location field. The Location field gives the URI of the proxy. The 
recipient is expected to repeat this single request via the proxy. 305 
responses MUST only be generated by origin servers.

     Note: [RFC2068] was not clear that 305 was intended to redirect a 
single request, and to be generated by origin servers only. Not 
observing these limitations has significant security consequences."

Make it...:

"9.3.6 305 Use Proxy

This status code is deprecated (see Section xyz) and SHOULD NOT be 
generated."

And then in the Changes section note what it used to be...:

"Deprecate 305 Use Proxy status code, because user agents did not 
implement it. It used to indicate that the requested resource must be 
accessed through the proxy given by the Location field. The Location 
field gave the URI of the proxy. The recipient was expected to repeat 
this single request via the proxy. (Section 9.3.6)"

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 11 Mar 2008 21:33:26 +1100

I don't think a SHOULD NOT is necessary; it should probably look  
something like 402 Payment Required IMO.

On 11/03/2008, at 8:52 PM, Julian Reschke wrote:

> The requested resource MUST be accessed through the proxy given by  
> the Location field. The Location field gives the URI of the proxy.  
> The recipient is expected to repeat this single request via the  
> proxy. 305 responses MUST only be generated by origin servers.
>
> implement it. It used to indicate that the requested resource must  
> be accessed through the proxy given by the Location field. The  
> Location field gave the URI of the proxy. The recipient was expected  
> to repeat this single request via the proxy. (Section 9.3.6)"
>
> BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Mar 2008 17:11:22 +0100

> something like 402 Payment Required IMO.

Well, the difference is that 402 doesn't come with any information about 
what it is, except for the name:

"10.4.3 402 Payment Required

This code is reserved for future use." -- 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.4.3>

So how about:

"9.3.6 305 Use Proxy

This code is reserved for future use (see Section xyz for information 
about how it was previously defined)."

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 14 Mar 2008 00:12:42 +0100

> this single request via the proxy. (Section 9.3.6)"

It has failed mainly because it isn't clearly defined if 305 is a
hop-by-hop redirection, or an end-to-end redirection. 2616 cleared some
of that, but still there is a lot of confusion about what 305 is
supposed to be used for.

The only meaningful definition I can see of 305 is as a hop-by-hop
redirection, with the added security restrictions that 305 messages must
not be accepted if received from a proxy.

Also it's a feature with very little practical use. The same
functionality is easily achieved using resource URLs to surrogate
servers instead, which most people find cleaner.

Additionally the security implications of getting 305 even the slightest
wrong can be very significant.

I am fine with deprecating 305 as "never implemented", moving it's
definition to an appendix explaining the differences between 2616 and
2616bis.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Mar 2008 14:30:55 +0100

Henrik Nordstrom wrote:
> ...
> ...

:-)

That's what I was trying to do.

Do you want to propose concrete text?

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 25 Mar 2008 15:41:44 +0100

> 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

---

From: David Morris <[email-masked]>
Date: Wed, 26 Mar 2008 21:07:01 -0800 (PST)

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 01 Apr 2008 16:48:22 +0200

Ok,

trying to make progress here.

I have checked in the following change with the goal to finally close 
this issue.

<http://tools.ietf.org/wg/httpbis/trac/changeset/235>

New text:

9.3.6.  305 Use Proxy

    The 305 status was defined in a previous version of this
    specification (see Appendix A.2), and is now deprecated.

and:

A.2.  Changes from RFC 2616

    ...

    Deprecate 305 Use Proxy status code, because user agents did not
    implement it.  It used to indicate that the requested resource must
    be accessed through the proxy given by the Location field.  The
    Location field gave the URI of the proxy.  The recipient was expected
    to repeat this single request via the proxy.  (Section 9.3.6)

    ...

If anyone disagrees with this resolution, please propose alternate text.

BR, Julian