hat=individual
personally I like the scope beyond http-only.
#1 The mis-configured header website part is in my view the main use case.
But scenarios where no content-type can be transmitted in the header,
like other protocols (e.g. ftp), filesystem, etc. seem to make sense too.
So in general I would support a broader scope.
Just my 5cents, Tobias
On 17/10/11 22:26, websec issue tracker wrote:
#15: Clarify scope of web sniffing
This issue may be broken down into several (is X in scope?) but this issue
is meant to cover the overall question to start with.
The introduction to the document cites the existence of mis-configured web
content served via HTTP as the primary justification for sniffing.
However, the document itself covers many situations beyond misconfigured
web content.
* web sites where content-type values are syntactically correct but
believed to be different from what was intended (because the content
itself doesn't match)
* situations where HTTP protocol content-type is syntactically incorrect,
duplicate, malformed.
* situations where no content-type is supplied at all via HTTP.
* situations where the content is not being delivered via HTTP at all, but
via other protocols.
There are a number of these situations, including web accesible material
delivered via ftp:, file: (on thumb drives?). The internet-draft is
currently normatively required by a W3C recommendation on zip packaging,
for example.
So the basic question is: what is the scope? The bug in the
specification is that the introduction and justification don't match the
apparent intent of the scope of the body.
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
