RE: 305/306 response codes

506 - Ahh, I get it. I would recommend putting your explanation into the
draft, it will make things much clearer.

Scoping - We do NOT scope our PAC/INS/Autoproxy implementation. A client
downloads an Autoproxy Jscript and that script is then executed on all
requests.

lifetime - Optional or not it isn't something the client wants to be
involved with. If the proxy doesn't want a browser to go through it
anymore let it send us a 305 so the browser will get a new PAC file.

options problems - As I have learned the hard way with DAV, negotiation
doesn't work. Besides this is just dancing around the bigger problem of
security. There is no way the browser is going to just accept a 305 even
if the server/proxy they are talking to does support Options. The 305
MUST come from someone who is trusted. How did this trust get
established in the first place?

In general it just seems fairly clear that using response codes to
perform proxy configuration is a bad idea. It may sound sexy but as the
myriad problems so far raised demonstrate, there are a lot of difficult
issues that are not going to get solved with a single HTTP round trip.
My suggestion is that we cut 305 from the HTTP 1.1 draft and let the
draft continue on its merry way. This issue can always be revisited in a
separate draft.

		Yaron

> -----Original Message-----
> From:	Josh Cohen [SMTP:josh@netscape.com]
> Sent:	Friday, June 06, 1997 6:18 PM
> To:	Yaron Goland
> Cc:	http-wg@cuckoo.hpl.hp.com
> Subject:	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 Tuesday, 10 June 1997 18:04:57 UTC