- From: T.V Raman <raman@google.com>
- Date: Thu, 31 Jul 2008 09:21:14 -0700
- To: seb@serialseb.com
- Cc: richard@cyganiak.de, raman@google.com, www-tag@w3.org, kidehen@openlinksw.com, tthibodeau@openlinksw.com
I'm a bit confused at this point by the question. Could you flesh out your example? HTML is a particularly good example, depending on how much you know about your HTML resource. Though there is much debate on this, in my experience, wel--formed XHTML survives well when served either as text/html or application/xml+xhtml. So if you have a resource under your control whose content you know is well-formed XHTML that you would rather serve as application/xml+xhtml, but you also know that many legacy agents only accept text/html In that case, you might definitely want to check the accept header and serve the appropriate response. Sebastien Lambla writes: > > Is it ever appropriate to configure content negotiation on the > > *representation-specific URIs*? So, if someone requests the specific URI > > for representation_1, but the Accept header indicates a preference for > > representation_3, should content negotiation kick in and representation_3 > > be served instead? > > If your url is the representation-specific one, then the conneg would fail > if the content-type of /resource.html is text/html and the Accept: only > contains application/xhtml+xml, as the representation is not the resource > and the url you requested is the one of the representation, not the > resource. I would return a 406. > > I'd understand the reasoning as being that if you dereference /resource.html > and get a 200 you can assert it is a document, if you were to conneg to > another url from the specific url you loose that assertion as defined in > httpRange-14 > > Sebastien Lambla -- Best Regards, --raman Title: Research Scientist Email: raman@google.com WWW: http://emacspeak.sf.net/raman/ Google: tv+raman GTalk: raman@google.com, tv.raman.tv@gmail.com PGP: http://emacspeak.sf.net/raman/raman-almaden.asc
Received on Thursday, 31 July 2008 16:22:30 UTC