> 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 EDT
This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:45 EDT