- From: Ernest Cline <ernestcline@mindspring.com>
- Date: Mon, 17 Nov 2003 21:58:25 -0500
- To: "Oskar Welzl" <oskar.welzl@pan.at>, "W3C HTML List" <www-html@w3.org>
> [Original Message] > From: Oskar Welzl <oskar.welzl@pan.at> > > 4) XHTML2 should define what happens if a retrieved resource > > does not match the type attributed to it via the type attribute > > or other method. At a minimum, a user agent must be able to > > provide an error message to the user and to present what > > would be presented, had the resource not been retrieved. > > Additional options as to what to do might be offered to the > > user if they so choose. > > I'd rather stick to HTML 4.01 here: > in case the MIMETYPE of the resource retrieved differs from > what @type says, the UA should simply forget about @type > and do what it would normally do with this kind of content > (which, of course, *might* be to display an error message). > the point, again, is: @type should be a hint about what will be > on the other end of the line, so that the UA can make > decisions *before* contacting the remote resource. as soon > as the file is retrieved, though, we usually know what it is - and > can act upon facts rather than upon hints. (of course, it may > happen that after retrieving a file, we still don't know what it's > supposed to be. in this case, again, the UA should try to > apply the MIMETYPE given by @type. if this doesn't work, > we'll have to present an error message.) Actually, I wasn't referring to what to do in the case of a discrepancy between the type attribute and the Content-Type header returned by HTTP. But if for example the Content-Type says that it is "image/jpeg" but the resource returned is not of that MIME type, what is the user agent to do? I think requiring the user agent to be able to both inform the user of the problem and make use of the alternative content while allowing the user agent to provide the user with other options of how to handle this error condition is reasonable.
Received on Monday, 17 November 2003 21:58:38 UTC