On 2010-09-16 15:17, Mikko Rantalainen wrote:
2010-09-13 16:44 EEST: Roger Hågensen:
On 2010-09-13 15:03, Mikko Rantalainen wrote:
And why do we need this? Because web servers are not behaving correctly
and are sending incorrect Content-Type headers? What makes you believe
that BINID will not be incorrectly used?
Because if they add a binary id then they obviously are aware of the
standard.
And because Apache developers were obviously aware of the "Content-Type"
header they implemented it correctly?... I
also fail to see future where server software vendors provide perfect
implementations.
We can dream can't we? *smiles*
Old servers/software would just pass the file through as they are
unaware so content type issues still exist there,
eventually old servers/software are rotate out until most are binary id
aware.
This is how rolling out new standards work.
A server would only add a binary id if none exist and it's certain (by
previous sniffing) that it's guess is correct,
How about we add a new parameter to Content-Type header instead? For
example, the server could send a file with a header such as
Content-Type: text/plain; charset=iso-8859-1; accuracy=0.9
and a "conforming" user agent should assume that there's 90% possibility
that the given content type is correct. If accuracy is 1.0 ("100%") then
sniffing MUST NOT be done. If the sniffing the UA is going has 95% hit
rate the results from such sniffing should probably be used instead of
HTTP provided content type if server provided accuracy is less than
0.95. I'll make it explicit that any sniffing done by UA should have a
probability of error attached to the result. A sniffing result without
probability for error has no value because otherwise a literal
"text/plain" is a good heuristic for any file (see also: "Apache").
This way server administrators could opt-out from any sniffing and an
incompetent server administrator could specify global accuracy of 0.1 or
something like that. Hopefully new web servers would then either provide
no default accuracy at all or specify some low enough value that allow
for sniffing.
My point is that there's no need for BINID. My suggestion above is
compatible with existing servers, content and UAs, as far as I know. In
addition, it would provide a way to declare that the given content type
should be trusted even if UA "thinks" that honoring the content type
causes problems for viewing the content.
Now we're getting somewhere, I really like this proposal.
Actually, with your idea a binary id would complement this as a server
supporting it could provide accuracy=1.0 in that case.
So I have to say that your accuracy parameter seems quick to add/support
(both in http header, and in HTML5 meta and other appropriate places?)
And I doubt the Apache Foundation will have much issues supporting this
either.
I guess we'll have to see what the rest thinks in this list but... a
solution this slick..
it certainly has my vote, nice work Mikko *thumbs up*.
--
Roger "Rescator" Hågensen.
Freelancer - http://EmSai.net/
