I wish to propose another tunnel which is a bit more practical in dealing with browser Accept header quirks.
At present, browsers implement the accept header oddly. to quote Jon Blower's recent email to the list: "Firefox 3: Accept header is "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8". Hence text/html is used, as expected. Chrome 0.2.149.30: Accept header is "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5". So Chrome prefers application/xml to text/html and hence gets an XML representation by default. Seems odd. IE7: Accept header does not include text/html, image/png or application/xml (!!) but does include "*/*" (yuck) so IE gets the variant that happens to be first in the Resource's list. With the above code this just happens to be text/html. So conneg doesn't really happen here at all." The current way of dealing with this is to use the User Agent (ua) string and then 'fix-up' the accepted media. However, we have unknown browsers, or companies who change the ua string of known browsers, or future versions that change the ua string, different ua strings for different os, etc. This is hard to maintain and leaves us open to serving incorrect representations to our users. - which happens with chrome at the moment. An alternative I suggest would be to ignore the accept header and provide html unless the person sending the request has gone to lengths to send something specific. At lengths could mean where the accept header did not contain any mention of html or xhtml at all. Then they would be shown the representation they requested in the accept headers. This could be wrapped up in a tunnel like setUserAgentTunnel() and be off by default. It would be an 'either or' to have this or the User Agent Tunnel on. Any thoughts or opinions? Jon ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2430633
