Re: Content security model

> HTTP does have a similar conflation, but nowhere near as severe.
> Content is mostly confined to the body and Routing is strictly
> confined to the Head. The parts that cross the line are
> Content-Encoding and Content-Type. Both of which are ignored in a Web
> Services context almost all the time.  Yes, a Web Service could
> support multiple character encodings but I cannot see any case where I
> would want the service to use Content-Encoding to make the choice.

This seems like a reasonable position for web services, but HTTP is also 
a transport for HTML in the context of web browsers, which when mixed 
with JavaScript and dynamic HTML, have done a remarkable job of 
confusing content with metadata, and declarative markup with 
Turning-complete languages.

There must be some security attacks which involve corrupting the headers 
or the request. Maybe HTTP/2.0 will have better framing to resist this.

"HTTP Request Splitting" comes to mind, or maybe adding a 
Content-Disposition header.

You may be right, though that it's easier to apply some kinds of 
security (signing or encryption) to a payload.

Received on Wednesday, 25 July 2012 17:59:40 UTC