RE: 305/306 response codes

> Sigh, you bastard, I wasn't planning on actually reading the damn thing!
> =)
> 
> *	506, um... maybe I'm just missing something but how does a
> client or proxy fail a redirection and how would this result in the
> server generating a 506? 506 seems like something you want the client or
> proxy to send the server, which is, of course, impossible.
Picture this:
    origin server
         |
       proxy
         |
      client


the origin server sends a 305, which the proxy refuses to follow 
for some reason.  The 506 is what I suggest that the proxy sends
back to the client, which otherwise would have no idea what happened.
(it wouldnt see the 305 )

> *	I don't like the MUST on having to show UI if you use the IPL to
> redirect. It should be a SHOULD. Client UI requirements have a nasty
> habit of being totally ignored, lets not contribute to that trend.
good point, i know.

> *	Action should be extensible so new ones can be added later. If a
> set-proxy header comes down with an unknown action then the header MUST
> be dropped. You also need to define a mechanism to prevent collisions
> amongst action names. I would suggest using URIs. The same logic goes
> for parameters and lifetime. You also need to add language to allow
> adding new parameters to set-proxy. However if a parameter is not
> recognized then only the parameter is dropped, not the whole header.

> *	Talking as a client implementer, I want nothing to do with
> scoping. I really do not want to have to start maintaining data
> structures to maintain scope information and then deal with matching. If
> someone wants something this complex let them use AutoProxy.
Why wouldnt this just be using the same scoping you already use
with you deal with an autoconfiguration file ? or PAC or INS or
whatever you call it.

> *	Also talking as a client implementer, I have no intention of
> implementing lifetime. Once we switch to a proxy or a AutoProxy file,
> that is it. Until the next change command comes in, we are committed.
we could make honoring the lifetine optional, but I fear what that
might lead to.

> *	Section 3.0 - All currently shipping 1.1 servers do not support
> 305/306 but would respond to an Options. In addition both Catapult and
> Apache's proxy appear 1.1 to the client and respond to options but don't
> actually understand 305/306.
yes, its too bad there's no way to do an options simply looking for
support of one thing.. ( not all the responses, or did I miss something )
Again as in 5.0 Notes (the section, not the product ), maybe
this is a good use for feature negotiation ?

> *	"A client or proxy SHOULD NOT accept a 306 from a proxy that it
> learned of via a 305 response code." - Again, talking as a client
> implementer, I am not going to start keeping a bunch of data structures
> around to record which proxies I learned of from which areas. I believe
Well, at some point we all are gonna have to bite the bullet and implement
a way of keeping track of which proxies we trust, this part of that.

> *	"A client or proxy MUST NOT accept a 305 response from an origin
> server." - Again, not to be too thick, but if origin servers can't send
this was a typo.. I meant "client or proxy MUST NOT accept a 306 from 
an origin server".. sorry.

> *	5.0 Notes - Exactly.
Hey, we agree!

> 
> In general a client doesn't want to get into the proxy management
> business. Basically we either want one proxy or a script specified
> through autoproxy. Anything more complex is just not worth the effort. I
this is a matter of opinion.  Yours is noted :)

> think 305 is just beautiful to let proxies build up hierarchies amongst
> themselves, just please leave us poor clients out of this. I also do not
> want to use 305 for proxy discovery. That is why we have SRVLOC,
no one is asserting discovery.. this is more a load balance or runtime
redirection.

> autoproxy, etc. What we really need is a header which proxies can
> include in all their requests which basically says "Yo dude, I'M A
> PROXY!!!" and now the recipient knows it can send 305/306 as needed in
> order to build up a proxy hierarchy.
dont you mean "Yo dude, I'M A WEASEL!!!" ? *duck*
actually isnt this what the 'forwarded' header is ?

> [ you made numerous comments about the apparent inability to 
> [ probe a proxy to determine if it supports 306/305 
This is an issue.  Can OPTIONS be modified to probe for a single 
feature, or is this what 'feature negotiation' is all about ?


-----------------------------------------------------------------------------
Josh Cohen				        Netscape Communications Corp.
Netscape Fire Department	               	       #include<disclaimer.h>
Server Engineering
josh@netscape.com                       http://home.netscape.com/people/josh/
-----------------------------------------------------------------------------

Received on Friday, 6 June 1997 18:20:37 UTC