Re: [widgets] Content-type sniffing and file extension to MIME mapping
On Mar 6, 2009, at 15:29, Marcos Caceres wrote: 2. The XHTML mapping should also appear in the file identification table [2]. What version of XHTML should I be pointing to? 1.0 or 1.1? Does it need to say anything more than that .xhtml maps to application/ xhtml+xml? The media type is defined by RFC 3236. As implemented, the media type isn't restricted to a particular point version of XHTML and browsers don't implement 1.1. (In fact, the media types in the table aren't defined by the specs in the Defined by column in general, but are defined by RFCs.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [widgets] Content-type sniffing and file extension to MIME mapping
Marcos Caceres schreef: Hi Laurens, As we no longer require user agents that conform the the packaging spec to support any media types, I have added xhtml as a default start file (extensions are .xhtml and .xht). This will be in the spec when I next check the spec in. Great, that adresses my concern. A few editorial comments though: 1. The MIME-type for XHTML is application/xhtml+xml, not application/html+xml as incorrectly apprears in the list of default start files [1]. 2. The XHTML mapping should also appear in the file identification table [2]. Thanks, ~Laurens [1] http://dev.w3.org/2006/waf/widgets/#default-start-files [2] http://dev.w3.org/2006/waf/widgets/#file-identification-table -- ~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~ Laurens Holst, student, university of Utrecht, the Netherlands Website: www.grauw.nl. Backbase employee; www.backbase.com begin:vcard fn:Laurens Holst n:Holst;Laurens email;internet:laur...@grauw.nl tel;cell:(+31) 06-41765048 version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: [widgets] Content-type sniffing and file extension to MIME mapping
On 3/6/09 2:24 PM, Laurens Holst wrote: Marcos Caceres schreef: Hi Laurens, As we no longer require user agents that conform the the packaging spec to support any media types, I have added xhtml as a default start file (extensions are .xhtml and .xht). This will be in the spec when I next check the spec in. Great, that adresses my concern. A few editorial comments though: 1. The MIME-type for XHTML is application/xhtml+xml, not application/html+xml as incorrectly apprears in the list of default start files [1]. Woops, fixed. 2. The XHTML mapping should also appear in the file identification table [2]. What version of XHTML should I be pointing to? 1.0 or 1.1?
Re: [widgets] Content-type sniffing and file extension to MIME mapping
Marcos Caceres schreef: 2. The XHTML mapping should also appear in the file identification table [2]. What version of XHTML should I be pointing to? 1.0 or 1.1? Short version: XHTML 1.1. Long version: The XHTML 1.0 spec has some interesting informative prose in section 4, “differences with HTML 4”, but that is probably repeated somewhere in HTML 5 (and generally common sense). The Appendix C HTML Compatibility Guidelines and the optional text/html MIME type do not apply in this case. XHTML 1.1 is XHTML 1.0 expressed using XHTML Modularization (something that is unfortunately lost in HTML5, it seems), and in addition to some minor modifications removes all the deprecated transitional stuff. As we all know, just because XHTML 1.1 removes the deprecated elements doesn’t mean that UAs no longer need to support it, but for authoring it seems good practice. Neither specification can be used stand-alone by the way; XHTML 1.0 references HTML4 and XHTML 1.1 references XHTML Modularization which references XHTML 1.0. ~Laurens -- Note: New email address! Please update your address book. ~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~ Laurens Holst, student, university of Utrecht, the Netherlands Website: www.grauw.nl. Backbase employee; www.backbase.com begin:vcard fn:Laurens Holst n:Holst;Laurens email;internet:laur...@grauw.nl tel;cell:(+31) 06-41765048 version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: [widgets] Content-type sniffing and file extension to MIME mapping
Hi Laurens, As we no longer require user agents that conform the the packaging spec to support any media types, I have added xhtml as a default start file (extensions are .xhtml and .xht). This will be in the spec when I next check the spec in. Kind regards, Marcos 2008/12/10 Laurens Holst lho...@students.cs.uu.nl: Marcos Caceres schreef: I'm not sure if any widget engines support application/xhtml+xml. I do not know your definition of ‘widget engine’, but Opera, Safari, Firefox all support application/xhtml+xml (and Prince XML too, but I don’t suppose that would be used for widgets :)). And last I checked, Internet Explorer doesn’t implement this specification anyway (neither do the other browsers, for that matter). Also, I am *not* requesting that implementors of this specification be required to support application/xhtml+xml, I am merely requesting that the .xhtml to application/xhtml+xml mapping is predefined, so that browsers which optionally *do* support it can be served content without having to explicitly create a MIME type mapping file. I think just adding it because it's a rec is not a valid argument. As Hixie argued, it may be supported by some UA's but it's not well understood by developers [1]. That document talks about sending XHTML as text/html, not XHTML in general. Also, it is the opinion of one person, one that I can only partially agree with. For example, one of the argument is based on the premise that HTML4 is SGML, something which we all know is not true. Also, actually HTML5 does support exactly this (even though Hixie doesn’t like it, last I heard). Implementation of HTML5 is well underway in many browsers, which supersedes XHTML in lots of ways. XHTML, that is the XML serialisation of HTML, is built-in HTML5. HTML5 does not supersede XHTML, it integrates it [1][2]. The HTML5 specification defines the application/xhtml+xml MIME type. In fact, the specification’s subtitle is “A vocabulary and associated APIs for HTML and XHTML”. You are aware of this, right? I think just mandating support for text/html is sufficient for widgets. Adding application/xhtml+xml just adds more baggage to widgets and no implementer has requested its support. I might as well just repeat myself (again): I am not requesting that XHTML support be added as a requirement for widget engines. I am just requesting that the mapping be predefined. However, if implementers request it, then we will consider adding it. It would be good if the people deciding on this had an informed opinion, instead of making assumptions and just following the ‘HTML good, XML bad’ mantra that seems to be popular among certain groups lately, and not hide behind statements like ‘if implementors request it’. I don’t understand the resistance against adding a MIME type mapping for a well-known and supported standard. As I explained before, adding a MIME type mapping does not actually mandate support for that MIME type in any way, if it does not support it the browser can respond as it normally would when being served application/xhtml+xml by an HTTP server. As I said before, I hope you are not using this specification to perpetuate your personal preference for text/html. HTML5 supports both XML and HTML serialisations, and the Widgets specification should not do otherwise. ~Laurens [1] http://dev.w3.org/html5/spec/Overview.html#relationship-to-html-4.01-and-dom2-html [2] http://dev.w3.org/html5/spec/Overview.html#html-vs-xhtml -- Note: New email address! Please update your address book. ~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~ Laurens Holst, student, university of Utrecht, the Netherlands Website: www.grauw.nl. Backbase employee; www.backbase.com -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Content-type sniffing and file extension to MIME mapping
2008/12/10 Laurens Holst [EMAIL PROTECTED]: Marcos Caceres schreef: Seems that there is still too much incompatibility to suggest application/xml support across Widget user agents. I think we should just stick with text/html. If authors want to use application/xml, then they can use content src=somefile type=application/xml / and hope for the best :) XHTML is a W3C standard that's been Recommended status for many years and has plenty of implementations (except for Internet Explorer, at this time). This should be more than enough to warrant inclusion in the list of MIME type mappings. I'm against using the application/xml type for XHTML by the way. A more specific MIME type is available and it has its use in certain occasions (e.g. for content negotiation, to determine whether the UA is requesting a human-readable XHTML version or a site-specific machine-readable XML version). XML is a transmission format that a lot of different formats make use of, however each format using XML is still a format on its own and should have its own MIME type. E.g. application/xhtml+xml should not be confused with application/rdf+xml, even though both could be served as application/xml. The content element is defined here: http://dev.w3.org/2006/waf/widgets/#the-content I'm not sure if any widget engines support application/xhtml+xml. I think just adding it because it's a rec is not a valid argument. As Hixie argued, it may be supported by some UA's but it's not well understood by developers [1]. Implementation of HTML5 is well underway in many browsers, which supersedes XHTML in lots of ways. I think just mandating support for text/html is sufficient for widgets. Adding application/xhtml+xml just adds more baggage to widgets and no implementer has requested its support. However, if implementers request it, then we will consider adding it. Kind regards, Marcos [1] http://hixie.ch/advocacy/xhtml. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Content-type sniffing and file extension to MIME mapping
On Tue, Dec 9, 2008 at 12:42 PM, Marcos Caceres [EMAIL PROTECTED] wrote: If authors want to use application/xml, then they can use content src=somefile type=application/xml / and hope for the best :) On Wed, Dec 10, 2008 at 12:06 AM, Adam Barth [EMAIL PROTECTED] wrote: I haven't been following the widget discussion very closely, so I apologize if this issue is understood already, but, in general, being able to coerce an arbitrary URL to application/xml is a big security problem. Can you point me to where the content tag is defined? this seems pointless. you're packaging your own widget. which means you control somefile and the manifest. you shouldn't be able to have somefile point *outside* widget, which means you were responsible for packaging somefile. if you're worried about a scanner, that's a problem the scanners will have to manage anyway, as this is a new thing which is going to have a slightly different profile than a web page. the wua isn't being tricked anywhere, it's doing as instructed and would know it was doing so. i can certainly serve a file named something as type application/xml over http, the difference here is that you're an archive (zip) which doesn't encode mime types and has no server.
Re: [widgets] Content-type sniffing and file extension to MIME mapping
On Tue, Dec 9, 2008 at 10:06 PM, Adam Barth [EMAIL PROTECTED] wrote: On Tue, Dec 9, 2008 at 12:42 PM, Marcos Caceres [EMAIL PROTECTED] wrote: If authors want to use application/xml, then they can use content src=somefile type=application/xml / and hope for the best :) I haven't been following the widget discussion very closely, so I apologize if this issue is understood already, but, in general, being able to coerce an arbitrary URL to application/xml is a big security problem. Can you point me to where the content tag is defined? The content element is defined here: http://dev.w3.org/2006/waf/widgets/#the-content Would certainly appreciate more details about the security threat. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Content-type sniffing and file extension to MIME mapping
Marcos Caceres schreef: I'm not sure if any widget engines support application/xhtml+xml. I do not know your definition of ‘widget engine’, but Opera, Safari, Firefox all support application/xhtml+xml (and Prince XML too, but I don’t suppose that would be used for widgets :)). And last I checked, Internet Explorer doesn’t implement this specification anyway (neither do the other browsers, for that matter). Also, I am *not* requesting that implementors of this specification be required to support application/xhtml+xml, I am merely requesting that the .xhtml to application/xhtml+xml mapping is predefined, so that browsers which optionally *do* support it can be served content without having to explicitly create a MIME type mapping file. I think just adding it because it's a rec is not a valid argument. As Hixie argued, it may be supported by some UA's but it's not well understood by developers [1]. That document talks about sending XHTML as text/html, not XHTML in general. Also, it is the opinion of one person, one that I can only partially agree with. For example, one of the argument is based on the premise that HTML4 is SGML, something which we all know is not true. Also, actually HTML5 does support exactly this (even though Hixie doesn’t like it, last I heard). Implementation of HTML5 is well underway in many browsers, which supersedes XHTML in lots of ways. XHTML, that is the XML serialisation of HTML, is built-in HTML5. HTML5 does not supersede XHTML, it integrates it [1][2]. The HTML5 specification defines the application/xhtml+xml MIME type. In fact, the specification’s subtitle is “A vocabulary and associated APIs for HTML and XHTML”. You are aware of this, right? I think just mandating support for text/html is sufficient for widgets. Adding application/xhtml+xml just adds more baggage to widgets and no implementer has requested its support. I might as well just repeat myself (again): I am not requesting that XHTML support be added as a requirement for widget engines. I am just requesting that the mapping be predefined. However, if implementers request it, then we will consider adding it. It would be good if the people deciding on this had an informed opinion, instead of making assumptions and just following the ‘HTML good, XML bad’ mantra that seems to be popular among certain groups lately, and not hide behind statements like ‘if implementors request it’. I don’t understand the resistance against adding a MIME type mapping for a well-known and supported standard. As I explained before, adding a MIME type mapping does not actually mandate support for that MIME type in any way, if it does not support it the browser can respond as it normally would when being served application/xhtml+xml by an HTTP server. As I said before, I hope you are not using this specification to perpetuate your personal preference for text/html. HTML5 supports both XML and HTML serialisations, and the Widgets specification should not do otherwise. ~Laurens [1] http://dev.w3.org/html5/spec/Overview.html#relationship-to-html-4.01-and-dom2-html [2] http://dev.w3.org/html5/spec/Overview.html#html-vs-xhtml -- Note: New email address! Please update your address book. ~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~ Laurens Holst, student, university of Utrecht, the Netherlands Website: www.grauw.nl. Backbase employee; www.backbase.com begin:vcard fn:Laurens Holst n:Holst;Laurens email;internet:[EMAIL PROTECTED] tel;cell:(+31) 06-41765048 version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: [widgets] Content-type sniffing and file extension to MIME mapping
Marcos Caceres schreef: Seems that there is still too much incompatibility to suggest application/xml support across Widget user agents. I think we should just stick with text/html. If authors want to use application/xml, then they can use content src=somefile type=application/xml / and hope for the best :) XHTML is a W3C standard that’s been Recommended status for many years and has plenty of implementations (except for Internet Explorer, at this time). This should be more than enough to warrant inclusion in the list of MIME type mappings. I’m against using the application/xml type for XHTML by the way. A more specific MIME type is available and it has its use in certain occasions (e.g. for content negotiation, to determine whether the UA is requesting a human-readable XHTML version or a site-specific machine-readable XML version). XML is a transmission format that a lot of different formats make use of, however each format using XML is still a format on its own and should have its own MIME type. E.g. application/xhtml+xml should not be confused with application/rdf+xml, even though both could be served as application/xml. ~Laurens -- Note: New email address! Please update your address book. ~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~ Laurens Holst, student, university of Utrecht, the Netherlands Website: www.grauw.nl. Backbase employee; www.backbase.com begin:vcard fn:Laurens Holst n:Holst;Laurens email;internet:[EMAIL PROTECTED] tel;cell:(+31) 06-41765048 version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: [widgets] Content-type sniffing and file extension to MIME mapping
Hi Laurens, 2008/12/10 Laurens Holst [EMAIL PROTECTED]: Marcos Caceres schreef: I'm not sure if any widget engines support application/xhtml+xml. I do not know your definition of 'widget engine', but Opera, Safari, Firefox all support application/xhtml+xml (and Prince XML too, but I don't suppose that would be used for widgets :)). And last I checked, Internet Explorer doesn't implement this specification anyway (neither do the other browsers, for that matter). Please read the spec for a definition of a widget user agent (widget engine). Also, I am *not* requesting that implementors of this specification be required to support application/xhtml+xml, I am merely requesting that the .xhtml to application/xhtml+xml mapping is predefined, so that browsers which optionally *do* support it can be served content without having to explicitly create a MIME type mapping file. This encourages fragmentation. We don't want developers developing in XHTML at all if those widgets are not going to work interoperably on HTML-only widget engines (and yes, those exists! a reference implementation of this specification is being developed on pocket IE). We don't forbid xhtml (hence the content element's type attribute.) I think just adding it because it's a rec is not a valid argument. As Hixie argued, it may be supported by some UA's but it's not well understood by developers [1]. That document talks about sending XHTML as text/html, not XHTML in general. I'm not going to be drawn into citations war about this. This isn't about that. Also, it is the opinion of one person, one that I can only partially agree with. For example, one of the argument is based on the premise that HTML4 is SGML, something which we all know is not true. And I quote, HTML 4 is an SGML application conforming to International Standard ISO 8879 -- Standard Generalized Markup Language [ISO8879]. The HTML4.01 spec says it's so. Browsers didn't follow the spec. By specification, HTML4.01 *is* SGML. If you deny this fact, then your notion of HTML has not been formally defined anywhere. Also, actually HTML5 does support exactly this (even though Hixie doesn't like it, last I heard). I'm not sure what this is. I also don't particularly care about what Hixie's position is on things. I'm capable of drawing my own conclusions from whatever evidence is available. Hixie's document, although advocating a position, formulates are logical argument backed by testable/verifiable evidence. Implementation of HTML5 is well underway in many browsers, which supersedes XHTML in lots of ways. XHTML, that is the XML serialisation of HTML, is built-in HTML5. HTML5 does not supersede XHTML, it integrates it [1][2]. The HTML5 specification defines the application/xhtml+xml MIME type. In fact, the specification's subtitle is A vocabulary and associated APIs for HTML and XHTML. You are aware of this, right? right. I think just mandating support for text/html is sufficient for widgets. Adding application/xhtml+xml just adds more baggage to widgets and no implementer has requested its support. I might as well just repeat myself (again): I am not requesting that XHTML support be added as a requirement for widget engines. I am just requesting that the mapping be predefined. If it's purely optional, it's not necessary to have it in the Widget spec. The mapping to a file extension It's already defined here: http://www.rfc-editor.org/rfc/rfc3236.txt However, if implementers request it, then we will consider adding it. It would be good if the people deciding on this had an informed opinion, instead of making assumptions and just following the 'HTML good, XML bad' mantra that seems to be popular among certain groups lately, and not hide behind statements like 'if implementors request it'. I don't appreciate you insulting me or other members of the working group by implying we are ignorant. I'm not hiding behind anything: as editor, my role is to represent the interests of members and the public in the spec. Also, I never said anything about good/bad aspects of HTML or XML. I don't understand the resistance against adding a MIME type mapping for a well-known and supported standard. As I explained before, adding a MIME type mapping does not actually mandate support for that MIME type in any way, if it does not support it the browser can respond as it normally would when being served application/xhtml+xml by an HTTP server. Why should XHTML get preferential treatment? By that logic I should also add RDF or whatever other obscure implemented specification supported by browsers. As I said before, I hope you are not using this specification to perpetuate your personal preference for text/html. HTML5 supports both XML and HTML serialisations, and the Widgets specification should not do otherwise. I don't have a personal preference (I think they both suck). When I worked as a proffesional Web developer, I
Re: [widgets] Content-type sniffing and file extension to MIME mapping
On Wed, Dec 10, 2008 at 2:55 AM, Marcos Caceres [EMAIL PROTECTED] wrote: The content element is defined here: http://dev.w3.org/2006/waf/widgets/#the-content Would certainly appreciate more details about the security threat. Thanks for the pointer. As timeless points out, this doesn't look like a security issue in this context because the content can be included only from within the widget. In other settings, you have to be careful about sites that let users upload content. For example, many sites let users upload images. If you take an HTTP response from one of these sites and override its Content-Type, you might be tricked into running the attacker's HTML in the honest site's security context. Adam
Re: [widgets] Content-type sniffing and file extension to MIME mapping
On Mon, Dec 8, 2008 at 9:04 AM, Jonas Sicking [EMAIL PROTECTED] wrote: On Sun, Dec 7, 2008 at 10:11 PM, Simon Pieters [EMAIL PROTECTED] wrote: On Fri, 05 Dec 2008 15:53:22 +0100, Marcos Caceres [EMAIL PROTECTED] wrote: Moi? a personal political agenda to rid the word of application/xhtml+xml? never! :P Seriously speaking, the list of types is supposed to reflect what the working group believes are the core development technologies that underpin widgets (for version 1.0, at least). I personally don't have an issue with including application/xhtml+xml, but I think it is unfair to require implementations to support it. Also, having optional supported types introduces fragmentation. However, we could add application/xhtml+xml and say that if the implementation does not handle xhtml, then it may treat it as text/html... but that is probably just asking for problems(?). I'd prefer if they treated it as application/xml instead. In fact, authors who want to use XHTML (or SVG, etc) in widgets could just use the .xml extension and it would work. In mozilla it gives different results if you serve usng application/xml, application/svg+xml or application/xhtml+xml. We create different types of Document nodes depending on what mimetype is used. So an SVG document, or plain XML document, won't have .cookies or .body for example. If this is ideal or not can of course be debated. I know Hixie has been advocating only having a single type of Document object, ever. Seems that there is still too much incompatibility to suggest application/xml support across Widget user agents. I think we should just stick with text/html. If authors want to use application/xml, then they can use content src=somefile type=application/xml / and hope for the best :) -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Content-type sniffing and file extension to MIME mapping
On Tue, Dec 9, 2008 at 12:42 PM, Marcos Caceres [EMAIL PROTECTED] wrote: If authors want to use application/xml, then they can use content src=somefile type=application/xml / and hope for the best :) I haven't been following the widget discussion very closely, so I apologize if this issue is understood already, but, in general, being able to coerce an arbitrary URL to application/xml is a big security problem. Can you point me to where the content tag is defined? Thanks, Adam
Re: [widgets] Content-type sniffing and file extension to MIME mapping
Marcos Caceres schreef: Moi? a personal political agenda to rid the word of application/xhtml+xml? never! :P ^_^ Seriously speaking, the list of types is supposed to reflect what the working group believes are the core development technologies that underpin widgets (for version 1.0, at least). I personally don't have an issue with including application/xhtml+xml, but I think it is unfair to require implementations to support it. Also, having optional supported types introduces fragmentation. However, we could add application/xhtml+xml and say that if the implementation does not handle xhtml, then it may treat it as text/html... but that is probably just asking for problems(?). I see. But, what I do not understand (hence also why I don’t really understand the objection against defining the mp3 and swf extensions…), why can you just not include a reasonably exhaustive list of specified extensions? Specifying a mapping from an extension to a MIME type does not mandate that format as a requirement for Widgets. Which formats are required for a Widgets implementation should be a separate concern. Also, as a matter of fact, out of the four major browsers, three support application/xhtml+xml (Firefox, Safari, Opera), and who knows, by the time IE implements this they might have support for it as well. If it would take a new Widgets spec version to include XHTML, by the time IE implements the MIME type we would have to wait another couple of years before the new Widgets version adds the extension to its list and browsers implement that? Of course, browsers can add their own MIME types (according to your text in your 2008-12-3 23:03 message), but then you miss the benefit of standardisation and one browser might go for something silly like .xht instead of .xhtml :). Or maybe it turns out that there is a need for a .xht extension mapping as well (as all other extensions have a three-character version). So, I see no real reason to exclude XHTML from the list. The Widgets specification can not predict what the state of affairs around XHTML will be in the next say, 5 years, when the specification gets implemented. It can specify a list of minimum required technologies that a browser has to support, and it is fine if XHTML is not part of that. However that should not preclude a standardised file extension/MIME type mapping. Different subject; About treating XHTML as text/html; I don’t know about that. The practice is fine by itself, I do that on my website and I would like to use it if I were to create a ‘widget’ (if necessary to support IE). But I do think it is better if such behaviour is a conscious decision by the author, so that he is fully aware that it is happening. As the zip file ‘replaces’ the web server, it would have to offer some kind of support for this. Probably the best way to do this is to keep the internal mappings simple, but adding support for multiple types to the mappings file (that can override browser mappings): .xhtml application/xhtml+xml;q=1.0,text/html;q=0.5 That would work :). ~Laurens -- Note: New email address! Please update your address book. ~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~ Laurens Holst, student, Utrecht University, the Netherlands Website: www.grauw.nl. Backbase employee; www.backbase.com begin:vcard fn:Laurens Holst n:Holst;Laurens email;internet:[EMAIL PROTECTED] tel;cell:(+31) 06-41765048 version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: [widgets] Content-type sniffing and file extension to MIME mapping
Marcos Caceres schreef: Ok, hearing no objections, then I propose we bake in the following file extensions into the spec (we can debate which MIME types to use after we settle on the extensions!): .html .htm .css .gif .jpeg .png .js .json .xml .txt The following we should probably bake in too: .mp3 .swf .wav .svg .ico We may bake in the following: xhtml Why ‘may’? It seems to me that application/xhtml+xml deserves a MIME type mapping just like text/html does. Unless you have a personal preference for text/html and want to perpetuate that in this specification? ;) ~Laurens -- Note: New email address! Please update your address book. ~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~ Laurens Holst, student, Utrecht University, the Netherlands Website: www.grauw.nl. Backbase employee; www.backbase.com begin:vcard fn:Laurens Holst n:Holst;Laurens email;internet:[EMAIL PROTECTED] tel;cell:(+31) 06-41765048 version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: [widgets] Content-type sniffing and file extension to MIME mapping
Hi Laurens, 2008/12/5 Laurens Holst [EMAIL PROTECTED]: Marcos Caceres schreef: Ok, hearing no objections, then I propose we bake in the following file extensions into the spec (we can debate which MIME types to use after we settle on the extensions!): .html .htm .css .gif .jpeg .png .js .json .xml .txt The following we should probably bake in too: .mp3 .swf .wav .svg .ico We may bake in the following: xhtml Why 'may'? It seems to me that application/xhtml+xml deserves a MIME type mapping just like text/html does. Unless you have a personal preference for text/html and want to perpetuate that in this specification? ;) Moi? a personal political agenda to rid the word of application/xhtml+xml? never! :P Seriously speaking, the list of types is supposed to reflect what the working group believes are the core development technologies that underpin widgets (for version 1.0, at least). I personally don't have an issue with including application/xhtml+xml, but I think it is unfair to require implementations to support it. Also, having optional supported types introduces fragmentation. However, we could add application/xhtml+xml and say that if the implementation does not handle xhtml, then it may treat it as text/html... but that is probably just asking for problems(?). Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Content-type sniffing and file extension to MIME mapping
On Fri, Dec 5, 2008 at 5:19 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Marcos Caceres wrote: Hi Laurens, 2008/12/5 Laurens Holst [EMAIL PROTECTED]: Marcos Caceres schreef: Ok, hearing no objections, then I propose we bake in the following file extensions into the spec (we can debate which MIME types to use after we settle on the extensions!): .html .htm .css .gif .jpeg .png .js .json .xml .txt The following we should probably bake in too: .mp3 .swf .wav .svg .ico We may bake in the following: xhtml Why 'may'? It seems to me that application/xhtml+xml deserves a MIME type mapping just like text/html does. Unless you have a personal preference for text/html and want to perpetuate that in this specification? ;) Moi? a personal political agenda to rid the word of application/xhtml+xml? never! :P Seriously speaking, the list of types is supposed to reflect what the working group believes are the core development technologies that underpin widgets (for version 1.0, at least). I personally don't have an issue with including application/xhtml+xml, but I think it is unfair to require implementations to support it. Also, having optional supported types introduces fragmentation. However, we could add application/xhtml+xml and say that if the implementation does not handle xhtml, then it may treat it as text/html... but that is probably just asking for problems(?). Ugh, please don't do that. XHTML treated as HTML is very bad [1]. Why not simply allow people to treat it as unsupported, just like i'd imagine implementations that don't support wav, svg or json to do. It was mainly because of [1] that I Ieft xhtml out. I don't want to encourage authors to use xhtml with widgets if it's not going to be widely supported by widget user agents (no implementer has asked for xhtml support to date). In Widgets version 2, we might introduce fallback on content, where you can do something like: widget content src=index.xhtml type=application/xhtml+xml cotent src=index.swf type=whateverTheFlash/typeIs content src=index.html type=text/html/ /content /content /widget -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Content-type sniffing and file extension to MIME mapping
On 2.12.2008 18.29, ext Marcos Caceres [EMAIL PROTECTED] wrote: On Tue, Dec 2, 2008 at 3:19 PM, Jere Kapyaho [EMAIL PROTECTED] wrote: snip Yes, it's .flac (or .fla in a pinch) for FLAC. Oh oh! .fla is a clash with Adobe flash files:( Well, that would have been for truly legacy systems only. :) However, when multiple file extensions map to the same MIME type, there could be other conflicts like this. I personally, don't think we should define a format that forces developers to include every file just to cover the use case where a file extension is missing. If the extension is missing, it could be on purpose. Or it could be there, but it could be just plain wrong, or ambiguous (think .jpg vs. .jpeg, or .htm vs. .html). The concept I envisioned is somewhat similar to the index of a JAR file. [1]. Also, I assume that some tool would be needed to generate this metadata list, as I don't see any developer ever doing this by hand because: 1. a widget could contain hundreds of files. 2. file names with spaces, and possibly other characters, would need to be URL encoded. 3. it would be tremendously error prone and hard to maintain. 4. developers would wonder why this is not done automatically by the widget engine, when they've never had to do it with any other widget engine before. If a widget has hundreds of files, nobody would try to do it by hand anyway (point #1). If the filename is UTF-8 and defined as a relative URI inside the package, it will have to be UTF-8-ified and URL-encoded. (point #2). I guess I envisioned a tool doing the assembly anyway (point #3). If we were going to add a mimetype override file, I would argue we should only do it based on file extensions. Note that I'm not pushing the method I described as *the* solution, but to me only point #4 of those above is critical. File extensions are by nature unreliable and ambiguous, but very commonly used as a way (or even the only way) of recognizing content. A more immediate problem in terms of the spec is that you will need to come up with all the 'important' file extensions up front, and the list will need to be updated later, perhaps frequently, depending on how exhaustive the initial list was. But the Apache style extension to MIME type mapping probably works adequately in this context also. [1] http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#JAR%20Index --Jere
Re: [widgets] Content-type sniffing and file extension to MIME mapping
On Tue, Dec 2, 2008 at 6:09 PM, Boris Zbarsky [EMAIL PROTECTED] wrote: Marcos Caceres wrote: That wouldn't be a problem in widgets, as we would say .css is always text/css. My point is that this doesn't seem like a reasonable requirement, necessarily. Do you have any suggestions as to how we might move forward? Or a different approach to solving the problem? -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Content-type sniffing and file extension to MIME mapping
Marcos Caceres wrote: Do you have any suggestions as to how we might move forward? Or a different approach to solving the problem? The problem being that a ZIP file doesn't know anything about the types of files in it? What Gecko does right now for jar: URIs is somewhat similar to what it does for file: URIs. Specifically: 1) If the caller expects a particular type and indicates that, use that type. For example, any jar: URI loaded from a link rel=stylesheet type=text/css will be treated as text/css. 2) If the caller has no type expectation, look up type based on extension. This doesn't use a particular hardcoded list but does a best-effort lookup based on a hardcoded override list in Gecko, the type+extension combinations the user's profile has seen and acted on before, the OS extension to type mappings, another hardcoded list of extension-to-type hints (which differ from the overrides in not overriding the OS mappings). 3) If step 2 did not find a type, use our standard unknown content sniffer (which sniffs based on various stuff including the URI, the data, etc). None of this is great for interoperability, of course, but it's no worse than anything that happens with file:// URIs. I suppose you could in fact define a small set of extensions that would interoperably be mapped to particular types in the context of widgets. You could also define a particular file in the package that contains extension-to-type mappings (either without the predefined mappings, or able to add to and override the predefined mappings). You'd need something like this for sane extensibility anyway, in my opinion. -Boris
Re: [widgets] Content-type sniffing and file extension to MIME mapping
On Tue, Dec 2, 2008 at 1:42 AM, Marcos Caceres [EMAIL PROTECTED] wrote: Ok, hearing no objections, then I propose we bake in the following file extensions into the spec (we can debate which MIME types to use after we settle on the extensions!): .jpeg you're missing .jpg which is fairly odd.
Re: [widgets] Content-type sniffing and file extension to MIME mapping
Marcos Caceres wrote on 11/29/2008 9:39 AM: I had a discussion with Henri Sivonen and a few other people in the HTML-WG about using HTML5's content-type sniffing as a way of deriving the MIME type of files inside a widget package. Henri suggested that we should primarily rely on file extensions as a way of mapping files to MIME types. Although relying on extensions can be potentially unreliable, it seems like a simple solution to a complicated problem. Content-sniffing can pose it's own problems, here's one example: http://www.gnucitizen.org/blog/backdooring-images/ For the spec, I guess it would mean including a table of file extension to MIME type mappings into the spec for common IANA registered types (MIME type registrations list file extensions). The Apache (httpd) project includes a file called mime.types that maps file extensions to MIME types. I haven't seen anything more extensive than Apache's. As a second line of defense, if there is no file extension, or the file extension does not map to the file extension to MIME table, then HTML content-type sniffing heuristics can be used. This paper describes how the major browsers do it: http://www.leviathansecurity.com/pdf/Flirting%20with%20MIME%20Types.pdf Firefox specifically appears to do it the way you're proposing here. - Bil
Re: [widgets] Content-type sniffing and file extension to MIME mapping
On Sat, 29 Nov 2008, Bil Corry wrote: Marcos Caceres wrote on 11/29/2008 9:39 AM: I had a discussion with Henri Sivonen and a few other people in the HTML-WG about using HTML5's content-type sniffing as a way of deriving the MIME type of files inside a widget package. Henri suggested that we should primarily rely on file extensions as a way of mapping files to MIME types. Although relying on extensions can be potentially unreliable, it seems like a simple solution to a complicated problem. Content-sniffing can pose it's own problems, here's one example: http://www.gnucitizen.org/blog/backdooring-images/ Content-sniffing providing privilege escalation is a problem, as is non-interoperable content-sniffing. However, assuming you define the content-sniffing to not have any privilege escalations, and assuming that all implementations implement the same thing, there's no problem. Note also that none of this applies to widgets, since the user has already given them as full a set of privileges as would be possible to obtain through content-sniffing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
