> Imagine, for example, that I want to experiment with SVG > files, but my ISP > doesn't know anything about SVG, or they know that it's still an > experimental standard, or for any other reason don't want to > change the > server configuration. In the mean time, the server continues > to send my > SVG files as plain/text. What am I to do, short of switching to a > different ISP? > > Having the TYPE attribute take precedence over the > Content-Type field would > allow authors to deal with such situations, instead of > relying on server > administrators. This is a good point. Another advantage of having the Content-Type inside the code is that it would permit us to send different media types within one "page". Or having the browser to choose to view one or another. A classic use of this feature would be for downloading files. Modern software download sites have a web page explaining how to download and install the file beeing sent, and will send the file to the client. This is done usually via a REFRESH (or redirect) action. What if the beginning of the HTML web page had a html content type instruction and at the end of the page, an instruction that will send to the browser the file + it's content type. More than that, what if the user/browser could choose between different formats of the file? Choose between a PDF, Doc or txt file? Choose between specific version of the document/software/platform? Same thing goes for video, music, etc. Patrice Calve Cactus Communication (819) 778-0313Received on Monday, 30 August 1999 08:41:01 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:49:18 GMT