Re: remove PATCH, COPY, MOVE, DELETE, etc.? Upgrade?

> > WRAPPED->Part of Dave Kristol's original extension proposal, with additions
> >   from myself and Rohit (for PEP).  I am not sure whether this qualifies
> >   or not.
>
> See Rohit's subsequent message. If the defender of WRAPPED can't
> decide which of the two alternatives:
>
> > Bottom line: WRAPPED should stay in, either with the
> > application/http restriction and PEP, or without any restriction, so
> > long as the client intends application/http. (Damned non-composable
> > content-types!)
>
> then how are the rest of us to decide?

Well, now wait a second; I can decide very clearly: the Content-Type of a  
WRAPPED message must allow application/http and message/http and should allow  
other types by private agreement. End of story.

Implementors would be required to loop messages back to themselves,  
permitting enhancement through Content-Encoding:, and PEP. Other servers would  
be allowed to accept varying MIME types; minimally conformant servers return  
501 for other media types.

OTOH, I have to agree with Larry that I don't yet see the same  
argument/demand for the other proposed use of Wrapped: sending multiple  
requests and multiple replies.

> > If it's left out, well, you can't build application security solutions within  
> > HTTP/1.1.
>
> Why not build them with SHTTP? or SSL?

Because, not to offend anyone's intelligence, application-layer security !=  
channel-layer, and I'd hope that HTTP security would be done *within* HTTP  
rather than in some security protocol that looks like pseudo-HTTP. That way,  
it will track the evolution of HTTP itself. For example, try sending a  
chunked-transfer-encoding stream through SHTTP: it can't, it would have to be  
buffered up, since SHTTP doesn't track new 1.1 encodings. Security outside  
HTTP cannot react as directly to new authentication schemes, interoperation  
with noninvolved proxies, etc.

Rohit Khare

Received on Friday, 23 February 1996 21:10:41 UTC