RE: ISSUE-24: A compromise on authoritative metadata using Accept?

Hmm, I wish I could get such clarity when failing to achieve sleep!

Although I've not studied the background to the original finding deeply, I
do like the approach. In particular, I like the idea of underpinning the
proposed behaviour of HTML 5 as an attempt to recover from non-conformant
use of HTTP.

Best wishes
Rhys

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of noah_mendelsohn@us.ibm.com
> Sent: 14 September 2007 05:46
> To: www-tag@w3.org
> Subject: ISSUE-24: A compromise on authoritative metadata 
> using Accept?
> 
> 
> We had some discussion last night of issue-24 [1].  From the 
> unapproved draft minutes:
> 
> "DC: our position on contentTypeOverride-24 is: if it says 
> text/plain, it's text/plain. Recent HTML 5 drafts say: if 
> you're looking for an image, treat what comes back as an 
> image, even if the MIME type says text/plain (or something 
> pretty close to that)"
> 
> We had a discussion that included some speculation that one 
> path would be to compromise our position on Authoritative 
> Metadata, and while I'm not particularly happy about the 
> prospect, I think it's worth looking at what the best 
> possible compromises might look like.  So, while having 
> trouble sleeping last night, the following admittedly idea came to me.
> 
> * We would stick with the story that Content-Type is the 
> authoritative source of media-type info for a retreived 
> representation.
> 
> * The HTML 5 spec will allow for the <img> tag game, but it 
> will state that users agents SHOULD issue an Accept: header, 
> e.g. for image/jpeg, in that case.
> 
> * The authoritative metadata finding (and perhaps a revised 
> RFC 2616) will
> state: as stated in section 14.1 of RFC 2616, a server SHOULD 
> respond with status code 406 if the requested type is not 
> available.  If the server is nonconformant and returns status 
> code 200 with some other type, then the user agent MAY, at 
> its own risk, infer that the data is of the requested type 
> (or one of the requested types), rather than of the type 
> given in the Content-type.  Ideally, the user agent should 
> warn the user that it is recovering from a non-conformant use of HTTP.
> 
> It seems to me that this has, among other things, the 
> desirable characteristic that the semantics are described at 
> the protocol level, which is not true if you just predicate 
> it all on: "If the link was from an <img> tag".
> 
> Rationale:
> 
> RFC 2616 [2] says:
> 
> "The Accept request-header field can be used to specify 
> certain media types which are acceptable for the response.  
> Accept headers can be used to indicate that the request is 
> specifically limited to a small set of desired types, as in 
> the case of a request for an in-line image."
> 
> [...]
> 
> "If an Accept header field is present, and if the server 
> cannot send a response which is acceptable according to the 
> combined Accept field value, then the server SHOULD send a 
> 406 (not acceptable) response."
> 
> So, if a client issues Accept: image/jpeg, and gets back 
> Status code 200 with Content-type: text/plain, it has Prima 
> Facie evidence that the server has violated RFC 2616.  The 
> presentation of the image is rationalized as a best effort to 
> recover from an error.
> 
> I'm suspect there are holes in this, but does it perhaps 
> suggest a promising direction?  Thanks.
> 
> Noah
> 
> [1] http://www.w3.org/2001/tag/2007/09/13-tagmem-minutes#item05
> [2] http://www.ietf.org/rfc/rfc2616.txt
> 
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
> 
>

Received on Friday, 14 September 2007 06:45:24 UTC