Re: HTTP/1.1 & Proxies

> We may well want to define what OPTIONS is actually good for
> (since otherwise, we might as well take it out), but for the
> particular issue at hand, which is 'finding broken HTTP/1.0'
> servers, it's not clear OPTIONS will do a lot of good.
> 
It isnt just testing for 'brokenness'.
It would be legitimate for a proxy which is 1.1, but
doesnt support something which is OPTIONAL or a MAY
in the spec.  This is the type of thing that comes
to mind with OPTIONS

> Unless we really hustle, it will be hard to add
> <do you comply with> <rfc2109>
> without leaving out some perfectly reasonable HTTP/1.1
> proxies that just didn't get to this new OPTIONS feature.
> 
> And, of course, it won't be RFC 2109 any more.
That was just an example.
But, that shows a good point for OPTIONS or PEP, because
you might want to know which cookie spec you support
Yes, proxies dont do cookies, but they will, there is a 
draft for proxy-cookies floating around.
Things like that are not part of the 1.1 spec, but 
you want to still be able to find out if it is supported.

> 
> > I see it in a similar light as TCN, except for communications options
> > or parameters instead of object attributes or languages.
> 
> I'm confused about what OPTIONS gives you that PEP doesn't
> do more broadly. Or is it that you don't think we need
> PEP but OPTIONS is OK?

This raises the question of wether or not we should
make these 'extras' like the whle 305/306 issue just 
PEP modules and not part of the 'base' spec.

> 
> Larry
> -- 
> http://www.parc.xerox.com/masinter


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

Received on Wednesday, 2 July 1997 01:56:33 UTC