- From: Daniel Stenberg <daniel@haxx.se>
- Date: Thu, 3 Jul 2008 17:51:39 +0200 (CEST)
- To: "'HTTP Working Group'" <ietf-http-wg@w3.org>
- cc: public-html@w3.org
On Thu, 3 Jul 2008, Justin James wrote: > There are tons of legitimate use cases here they you have completely > overlooked. For example, lots of server side applications throw out content > of a type different from what their file extension would indicate. For > example, the earliest "hit counter" programs were .cgi or .pl files > (typically) generating image/gif or image/jpeg content. The Web servers were > set up explicitly to serve the output of those applications as text/html. > And a great many developers had no idea that they needed to change the > Content-type at the code level to make this work. Content sniffing made life > easier for these developers. Uh, that doesn't make sense. Sure, some scripts output wrong Content-Type. Then no browser can output it correctly and thus you fix the server side. But, this system with bad Content-Type outputs still showing up nicely only works if the client *already* have does this "sniffing" business and thus they more or less encouraged the server-side hackers to remain sloppy. So this cannot have been a case where the browser adapted to how servers work, since servers would hardly ever have worked this way if some browsers didn't already support it... I find this "I promise this time I really mean that the type is what I say" attribute hilariously funny. -- / daniel.haxx.se
Received on Thursday, 3 July 2008 15:52:49 UTC