W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Handling of locally-served files via XHR and as iframe source

From: SULLIVAN, BRYAN L (ATTCINW) <BS3131@att.com>
Date: Fri, 19 Mar 2010 14:31:09 -0700
Message-ID: <8080D5B5C113E940BA8A461A91BFFFCD1130A2BB@BD01MSXMB015.US.Cingular.Net>
To: <public-webapps@w3.org>
Hi all,

This is a question for both the Webapps Widgets and Web API followers.

In testing widget engine rendering of plain text files as the source of
an iframe, I came across a problem I need your input on. It appears that
when a widget retrieves a file from the widget package using XHR *OR* as
the SRC attribute of an iframe, there are few if any headers returned,
and no content-type header. This may be because the platform has no
file-extension to MIME type mapping ala a web server, and no server
application creating the content-type header directly. But it is
problematic nonetheless.

It has at least a couple of troublesome side-effects:
1)	It apparently confuses the web runtime (at least some of them)
in how the content should be rendered when referenced as the source of
an iframe. The expected behavior (to me) is that plain text is displayed
as preformatted text, and HTML as normal markup. But what specifically
is the guidance for that behavior: the content-type header, or an
analysis of the content? Is there a normative requirement on how content
should be handled when locally retrieved?
2)	The lack of a content-type header means that when the content is
retrieved, any Javascript logic that would process or display it in a
specific way is more complicated, i.e. the Javascript must either know
the content type inherently, use some type of rules (e.g. extension
mapping), get the metadata from somewhere else, or interpret the
content. Extension mapping may not be too difficult, but this is a
significant difference between the processing of a webapp using a server
source and Webapps using local files.
3)	When there is actually a local server that can handle HTTP
requests, the results are likely to be different (i.e. as a web server
would behave). This will likely be more common in the future. As a
result, the webapp will need to handle varying results on different
devices, and this could also affect the web runtime rendering of

Knowing what is the expected behavior will at least make it possible to
give guidance for developers.

Bryan Sullivan | AT&T
Received on Friday, 19 March 2010 21:31:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:05 UTC