- From: <bugzilla@jessica.w3.org>
- Date: Wed, 02 Mar 2011 04:56:59 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12217 Summary: Suggestion: Allow other 'Content-Type's to result from javascript: scheme URI dereferencing Product: HTML WG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: HTML5 spec (editor: Ian Hickson) AssignedTo: ian@hixie.ch ReportedBy: l0mars01@yahoo.com QAContact: public-html-bugzilla@w3.org CC: mike@w3.org, public-html-wg-issue-tracking@w3.org, public-html@w3.org http://www.w3.org/TR/html5/webappapis.html#javascript-protocol Currently, dereferencing a javascript: scheme URI treats its script evaluation result as the body of an HTTP response with Content-Type 'text/html'. Navigation then uses Media Type Sniffing to adjust this Content-Type and dispatch corresponding processing. http://www.w3.org/TR/html5/fetching-resources.html#content-type-sniffing-0 According to 'Media Type Sniffing', the sniffed content type is either 'text/html', 'application/rss+xml', or 'application/atom+xml'. This precludes processing for other media types (eg, other XML media types like 'application/xhtml+xml' or 'image/svg+xml') a javascript: URI could generate. I propose allowing the script result to explicitly specify the HTTP 'Content-Type' entity header as if it were a partial HTTP response lacking a start-line. Eg, evaluating the script could result in a string like this: Content-Type: <media-type> <message-body> The user-agent could supply a function to facilitate writing these correctly (inserting field-names, colons, and carriage return linefeed sequences; cleaning the content; etc). I invite the reader to consider other options if this one is unsatisfactory. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 2 March 2011 04:57:01 UTC