Re: HTTP/1.1 & Proxies
Josh Cohen (josh@netscape.com)
Wed, 2 Jul 1997 01:50:20 -0700 (PDT)
> 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/
-----------------------------------------------------------------------------