- From: T.V Raman <raman@google.com>
- Date: Thu, 31 Jul 2008 10:03:03 -0700
- To: richard@cyganiak.de
- Cc: raman@google.com, seb@serialseb.com, www-tag@w3.org, kidehen@openlinksw.com, tthibodeau@openlinksw.com
Thanks for the clarification -- I understand your specific question much better now. I dont think you should respond with a 406 -- since that is the least helpful of all to the client. If the client requests resquest.html, and says it *only* accepts mime-type json, and you actually have a json representation available, it is really a toss-up as to what you would send. I myself tend to lean toward sending the JSON representation in this case, mostly because I beleive that the content-type should be trusted more than the infered mime-type available through the URL extension --- but that is a contentious topic in its own right. But this is a good issue that you have raised --- and is an example of two pieces of the HTTP Request being in conflict, with the specifications giving no clear guidance as to how to break the conflict --- especially when taken in context of how user-agents behave at present. Richard Cyganiak writes: > Raman, > > My question was not at all about HTML vs. XHTML, Sebastien injected > that angle into the thread in a somewhat unhelpful way. I'm not > interested in hearing yet more people's opinions on the issue. I ask > for clarification of a detail in the TAG finding because I'm not sure > how to interpret the finding's intention. > > Let's say I have > > /resource (generic information resource with HTML and JSON > variants) > /resource.html (a HTML specific URI) > /resource.json (a JSON specific URI) > > Now let's say I request /resource.json with an Accept header of > "Accept: text/html". What should happen? > > One opinion is that the JSON should be served anyway, because the URI > identifies a specific variant. > > Another opinion is that the HTML should be served, or redirected to, > because that's what the client asked for and the server has it > available. > > (A third opinion is that 406 should be answered, as suggested by > Sebastien.) > > What I'm asking for is simply a clarification of the advice in the > spec. Did you intend that there be content negotiation on the > representation_i URIs? > > Cheers, > Richard > > > On 31 Jul 2008, at 17:21, T.V Raman wrote: > > > > > > > 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 > > > > -- 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 17:04:00 UTC