RE: Content Negotiation for Safari 4. Any way to override?

2009-06-29 Thread Jerome Louvel
Hi all,

I don't think that keeping the equalsIgnoreCase() method call do any harm. I 
suggest to keep it for flexibility purpose.

I've checked the HTTP spec, but nothing is said about case sensitivity for 
product tokens:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.8

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com




-Message d'origine-
De : Thierry Boileau [mailto:thierry.boil...@noelios.com] 
Envoyé : vendredi 26 juin 2009 07:54
À : discuss@restlet.tigris.org
Objet : Re: Content Negotiation for Safari 4. Any way to override?

Hello,

well, I'm afraid that I'm the author of the change...
Let's see with Jérôme if we keep the equalsIgnorCase test or not.

best regards,
Thierry Boileau

 Hello Bruno, Bruce,

 well that's weird, the current 2.0 release (in the svn repository) uses 
 equalsIgnoreCase not equals. And I was not aware this had changed.


 best regards,
 Thierry Boileau
   
 Hi Bruce/Thierry,

 It seems that the code has changed between version 1.1 and 2.0.

 In 1.1.5, com.noelios.restlet.application.TunnelFilter uses 
 'equalsIgnoreCase' (line 388), whereas in the trunk (2.0), 
 org.restlet.engine.application.TunnelFilter uses 'equals' (line 528).

 I think it makes sense to use 'equals' instead of 'equalsIgnoreCase' 
 (although I'm not sure which one is best), but the accept.properties 
 files should probably be updated to reflect this change (the version in 
 the trunk still uses lower case for all agent names).

 Best wishes,

 Bruno.

 Bruce Cooper wrote:
   
 
 Hi guys,

 I have found that the agentName is reporting as Safari with a capitol S 
 whereas the standard file has it listed with a lowercase s, so I've 
 needed to add a separate rule in accept.properties.  Because I want to 
 only override the default Accept that is being sent through (and so that 
 I can put in other accepts in XMLHttpRequest requests and not have them 
 overridden)//, I think it is best to include the acceptOld as shown below://

 #Safari
 agentName: Safari
 acceptOld: 
 application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
 acceptNew: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

 This appears to work for me, so I'm happy.  Let me know if you think it 
 is a good solution.

 Bruce.
 
   
 --
 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2365378


 

 --
 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2365482



--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2365596

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2366276


Re: Content Negotiation for Safari 4. Any way to override?

2009-06-25 Thread Thierry Boileau
Hello Bruno,
could you try by removing the acceptOld line? It is not mandatory.

best regards,
Thierry Boileau

 Hi Thierry,

 I'm not entirely sure what the intended behaviour of the TunnelService 
 (regarding user-agents) is. Could you confirm this should be as follow 
 (assuming the user agent tunnel is switched on in the service)?


 Step 1. The TunnelService parses the 'User-Agent' header and compares it 
 to org/restlet/data/agent.properties, therefore populating agent 
 attributes in the client info class.

 For example (with Safari 4):
 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us) 
 AppleWebKit/530.18 (KHTML, like Gecko) Version/4.0.1 Safari/530.18

 -
 {agentOsShortName=Macintosh, osData= en-us, agentName=Safari, 
 mozillaVersion=5.0, appleWebKitComment=KHTML, like Gecko, 
 familyVersion=4.0.1, agentVersion=530.18, agentOs=Intel Mac OS X 10_5_7, 
 appleWebKitVersion=530.18}

 Step 2. The service then looks into 
 org/restlet/service/accept.properties, if the 'agentName' (in a given 
 block in this file) matches the 'agentName' in the agent attributes and 
 if the 'acceptOld' line (in the same block) matches the original 
 'Accept' header in the request, then 'Accept' is replaced with the value 
 in 'acceptNew'.



 In the test above, the agentName is detected properly, but it seems the 
 blank line in the acceptOld config file doesn't mean it's a wildcard, so 
 there should probably be the actual Accept header sent by Safari in this 
 configuration file. This may be the reason why it doesn't work (it seems 
 to work when that line is configured to match the Accept header sent).


 Best wishes,

 Bruno.



 P.S.: Below are a few User-Agent and Accept headers I've been able to 
 gather.

 - Firefox 2 on XP:
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.20) 
 Gecko/20081217 Firefox/2.0.0.20 (.NET CLR 3.5.30729)
 Accept: 
 text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

 (I was surprised to see that this one doesn't seem to be recognised as 
 'agentName=Firefox' but 'Mozilla'; here are the attributes: 
 {agentName=Mozilla, osData=Windows NT 5.1; en-GB; rv:1.8.1.20) 
 Gecko/20081217 Firefox/2.0.0.20 (.NET CLR 3.5.30729, agentVersion=5.0, 
 agentOs=Windows}.)


 - Browser in the GWT Eclipse plugin:
 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) 
 Gecko/20050920
 Accept: 
 text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

 - iPod Touch (FW 2.2.1, not the latest):
 User-Agent: Mozilla/5.0 (iPod; U; CPU iPhone OS 2_2_1 like Mac OS X; 
 en-us) AppleWebKit/525.18.1 (KHTML, like Gecko) Version/3.1.1 
 Mobile/5H11 Safari/525.20
 Accept: 
 text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

 - MSIE 8 on XP:
 Accept: */*
 User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; 
 Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1; .NET CLR 
 3.0.4506.2152; .NET CLR 3.5.30729)

 - Safari 4 on XP:
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) 
 AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Safari/530.17
 Accept: 
 application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

 - Safari 4 on OSX:
 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us) 
 AppleWebKit/530.18 (KHTML, like Gecko) Version/4.0.1 Safari/530.18
 Accept: 
 application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

 Thierry Boileau wrote:
   
 Hi Bruce,

 can you send us the content of the user-agent header? We will complete 
 the default agent.properties file.

 best regards,
 Thierry Boileau
 
 Hi guys,

 I'm setting up a restlet app at the moment, and I'd like to set it up so 
 that if a user uses a browser to access a resource, he gets given a nicely 
 formatted HTML page, but if he separately asks for XML or JSON he gets a 
 machine parsable response.  Its all working well on Firefox, but I'm having 
 some issues getting it working on Safari 4.

 It looks like the problem is the Accept: header that is being sent in by 
 Safari.  Its 

 application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

 This causes the content negotiation process to favor xml as an output over 
 html, as html has a priority of 0.9.  I tried xhtml, which has the same 
 priority as xml, but it looks like it still chooses xml (presumably it is 
 random which response you get if they have the same priority).

 Is there a way I can override Safari's preferences?  I know that it is 
 asking to have xml as the highest priority, but frankly I think that is 
 wrong.

 Any suggestions that you can give would be appreciated.

 Bruce.
   

 --
 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2365031




Re: Content Negotiation for Safari 4. Any way to override?

2009-06-25 Thread Bruce Cooper
Hi guys,

I have found that the agentName is reporting as Safari with a capitol S
whereas the standard file has it listed with a lowercase s, so I've needed
to add a separate rule in accept.properties.  Because I want to only
override the default Accept that is being sent through (and so that I can
put in other accepts in XMLHttpRequest requests and not have them
overridden)*, I think it is best to include the acceptOld as shown below:*

#Safari
agentName: Safari
acceptOld:
application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
acceptNew: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

This appears to work for me, so I'm happy.  Let me know if you think it is a
good solution.

Bruce.


--
www.brucecooper.net - 0417 986 274


2009/6/25 Thierry Boileau thierry.boil...@noelios.com

 Hello Bruno,
 could you try by removing the acceptOld line? It is not mandatory.

 best regards,
 Thierry Boileau

  Hi Thierry,
 
  I'm not entirely sure what the intended behaviour of the TunnelService
  (regarding user-agents) is. Could you confirm this should be as follow
  (assuming the user agent tunnel is switched on in the service)?
 
 
  Step 1. The TunnelService parses the 'User-Agent' header and compares it
  to org/restlet/data/agent.properties, therefore populating agent
  attributes in the client info class.
 
  For example (with Safari 4):
  User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us)
  AppleWebKit/530.18 (KHTML, like Gecko) Version/4.0.1 Safari/530.18
 
  -
  {agentOsShortName=Macintosh, osData= en-us, agentName=Safari,
  mozillaVersion=5.0, appleWebKitComment=KHTML, like Gecko,
  familyVersion=4.0.1, agentVersion=530.18, agentOs=Intel Mac OS X 10_5_7,
  appleWebKitVersion=530.18}
 
  Step 2. The service then looks into
  org/restlet/service/accept.properties, if the 'agentName' (in a given
  block in this file) matches the 'agentName' in the agent attributes and
  if the 'acceptOld' line (in the same block) matches the original
  'Accept' header in the request, then 'Accept' is replaced with the value
  in 'acceptNew'.
 
 
 
  In the test above, the agentName is detected properly, but it seems the
  blank line in the acceptOld config file doesn't mean it's a wildcard, so
  there should probably be the actual Accept header sent by Safari in this
  configuration file. This may be the reason why it doesn't work (it seems
  to work when that line is configured to match the Accept header sent).
 
 
  Best wishes,
 
  Bruno.
 
 
 
  P.S.: Below are a few User-Agent and Accept headers I've been able to
  gather.
 
  - Firefox 2 on XP:
  User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.20)
  Gecko/20081217 Firefox/2.0.0.20 (.NET CLR 3.5.30729)
  Accept:
 
 text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
 
  (I was surprised to see that this one doesn't seem to be recognised as
  'agentName=Firefox' but 'Mozilla'; here are the attributes:
  {agentName=Mozilla, osData=Windows NT 5.1; en-GB; rv:1.8.1.20)
  Gecko/20081217 Firefox/2.0.0.20 (.NET CLR 3.5.30729, agentVersion=5.0,
  agentOs=Windows}.)
 
 
  - Browser in the GWT Eclipse plugin:
  User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12)
  Gecko/20050920
  Accept:
 
 text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
 
  - iPod Touch (FW 2.2.1, not the latest):
  User-Agent: Mozilla/5.0 (iPod; U; CPU iPhone OS 2_2_1 like Mac OS X;
  en-us) AppleWebKit/525.18.1 (KHTML, like Gecko) Version/3.1.1
  Mobile/5H11 Safari/525.20
  Accept:
 
 text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
 
  - MSIE 8 on XP:
  Accept: */*
  User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;
  Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1; .NET CLR
  3.0.4506.2152; .NET CLR 3.5.30729)
 
  - Safari 4 on XP:
  User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US)
  AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Safari/530.17
  Accept:
 
 application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
 
  - Safari 4 on OSX:
  User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us)
  AppleWebKit/530.18 (KHTML, like Gecko) Version/4.0.1 Safari/530.18
  Accept:
 
 application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
 
  Thierry Boileau wrote:
 
  Hi Bruce,
 
  can you send us the content of the user-agent header? We will complete
  the default agent.properties file.
 
  best regards,
  Thierry Boileau
 
  Hi guys,
 
  I'm setting up a restlet app at the moment, and I'd like to set it up
 so that if a user uses a browser to access a resource, he gets given a
 nicely formatted HTML page, but if he separately asks for XML or JSON he
 gets a machine parsable response.  Its all working well on Firefox, but I'm
 having some 

Re: Content Negotiation for Safari 4. Any way to override?

2009-06-25 Thread Bruce Cooper
Hi Thierry,
As Bruno said, the user agent is:


   1. Accept:

   
application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
   2. User-Agent:
   Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-au)
   AppleWebKit/530.18 (KHTML, like Gecko) Version/4.0.1 Safari/530.18


Which is exactly the same as Safari 3 as far as I am aware, apart from
version numbers.  Thanks for the links, I'll look into it now.

Bruce.


--
www.brucecooper.net - 0417 986 274


2009/6/24 Thierry Boileau thierry.boil...@noelios.com

 Hello Bruce,

 could you have a look at this page [1] of the user guide? And at the
 javadocs of the tunnelService class [2], and ClientInfo class [3].
 The solution is based on two properties files.
 One (agent.properties), helps to match the user-agent string (sent by
 the browser) and extract some information such as the agent name
 (Safari, for example). Some browsers have been identified (especially
 Safari 2 and 3).
 The other one is called accept.properties, and helps to override the
 accept header of a browser.
 If you want to activate this mechanism, turn on the UserAgentTunnel
 attribute of the Application#tunnelService.


 best regards,
 Thierry Boileau
 [1] http://wiki.restlet.org/docs_1.2/207-restlet.html
 [2]

 http://www.restlet.org/documentation/2.0/api/org/restlet/service/TunnelService.html
 [3]

 http://www.restlet.org/documentation/1.1/api/org/restlet/data/ClientInfo.html#getAgentAttributes()


  Hi guys,
 
  I'm setting up a restlet app at the moment, and I'd like to set it up so
 that if a user uses a browser to access a resource, he gets given a nicely
 formatted HTML page, but if he separately asks for XML or JSON he gets a
 machine parsable response.  Its all working well on Firefox, but I'm having
 some issues getting it working on Safari 4.
 
  It looks like the problem is the Accept: header that is being sent in by
 Safari.  Its
 
 
 application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
 
  This causes the content negotiation process to favor xml as an output
 over html, as html has a priority of 0.9.  I tried xhtml, which has the same
 priority as xml, but it looks like it still chooses xml (presumably it is
 random which response you get if they have the same priority).
 
  Is there a way I can override Safari's preferences?  I know that it is
 asking to have xml as the highest priority, but frankly I think that is
 wrong.
 
  Any suggestions that you can give would be appreciated.
 
  Bruce.
 
  --
 
 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2364881
 
 

 --

 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2364926


--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2365190

Re: Content Negotiation for Safari 4. Any way to override?

2009-06-25 Thread Bruno Harbulot
Hi Bruce/Thierry,

It seems that the code has changed between version 1.1 and 2.0.

In 1.1.5, com.noelios.restlet.application.TunnelFilter uses 
'equalsIgnoreCase' (line 388), whereas in the trunk (2.0), 
org.restlet.engine.application.TunnelFilter uses 'equals' (line 528).

I think it makes sense to use 'equals' instead of 'equalsIgnoreCase' 
(although I'm not sure which one is best), but the accept.properties 
files should probably be updated to reflect this change (the version in 
the trunk still uses lower case for all agent names).

Best wishes,

Bruno.

Bruce Cooper wrote:
 Hi guys,
 
 I have found that the agentName is reporting as Safari with a capitol S 
 whereas the standard file has it listed with a lowercase s, so I've 
 needed to add a separate rule in accept.properties.  Because I want to 
 only override the default Accept that is being sent through (and so that 
 I can put in other accepts in XMLHttpRequest requests and not have them 
 overridden)//, I think it is best to include the acceptOld as shown below://
 
 #Safari
 agentName: Safari
 acceptOld: 
 application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
 acceptNew: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
 
 This appears to work for me, so I'm happy.  Let me know if you think it 
 is a good solution.
 
 Bruce.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2365378


Re: Content Negotiation for Safari 4. Any way to override?

2009-06-25 Thread Thierry Boileau
Hello,

well, I'm afraid that I'm the author of the change...
Let's see with Jérôme if we keep the equalsIgnorCase test or not.

best regards,
Thierry Boileau

 Hello Bruno, Bruce,

 well that's weird, the current 2.0 release (in the svn repository) uses 
 equalsIgnoreCase not equals. And I was not aware this had changed.


 best regards,
 Thierry Boileau
   
 Hi Bruce/Thierry,

 It seems that the code has changed between version 1.1 and 2.0.

 In 1.1.5, com.noelios.restlet.application.TunnelFilter uses 
 'equalsIgnoreCase' (line 388), whereas in the trunk (2.0), 
 org.restlet.engine.application.TunnelFilter uses 'equals' (line 528).

 I think it makes sense to use 'equals' instead of 'equalsIgnoreCase' 
 (although I'm not sure which one is best), but the accept.properties 
 files should probably be updated to reflect this change (the version in 
 the trunk still uses lower case for all agent names).

 Best wishes,

 Bruno.

 Bruce Cooper wrote:
   
 
 Hi guys,

 I have found that the agentName is reporting as Safari with a capitol S 
 whereas the standard file has it listed with a lowercase s, so I've 
 needed to add a separate rule in accept.properties.  Because I want to 
 only override the default Accept that is being sent through (and so that 
 I can put in other accepts in XMLHttpRequest requests and not have them 
 overridden)//, I think it is best to include the acceptOld as shown below://

 #Safari
 agentName: Safari
 acceptOld: 
 application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
 acceptNew: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

 This appears to work for me, so I'm happy.  Let me know if you think it 
 is a good solution.

 Bruce.
 
   
 --
 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2365378


 

 --
 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2365482



--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2365596


Re: Content Negotiation for Safari 4. Any way to override?

2009-06-24 Thread Bruno Harbulot
Hi Thierry,

I'm not entirely sure what the intended behaviour of the TunnelService 
(regarding user-agents) is. Could you confirm this should be as follow 
(assuming the user agent tunnel is switched on in the service)?


Step 1. The TunnelService parses the 'User-Agent' header and compares it 
to org/restlet/data/agent.properties, therefore populating agent 
attributes in the client info class.

For example (with Safari 4):
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us) 
AppleWebKit/530.18 (KHTML, like Gecko) Version/4.0.1 Safari/530.18

-
{agentOsShortName=Macintosh, osData= en-us, agentName=Safari, 
mozillaVersion=5.0, appleWebKitComment=KHTML, like Gecko, 
familyVersion=4.0.1, agentVersion=530.18, agentOs=Intel Mac OS X 10_5_7, 
appleWebKitVersion=530.18}

Step 2. The service then looks into 
org/restlet/service/accept.properties, if the 'agentName' (in a given 
block in this file) matches the 'agentName' in the agent attributes and 
if the 'acceptOld' line (in the same block) matches the original 
'Accept' header in the request, then 'Accept' is replaced with the value 
in 'acceptNew'.



In the test above, the agentName is detected properly, but it seems the 
blank line in the acceptOld config file doesn't mean it's a wildcard, so 
there should probably be the actual Accept header sent by Safari in this 
configuration file. This may be the reason why it doesn't work (it seems 
to work when that line is configured to match the Accept header sent).


Best wishes,

Bruno.



P.S.: Below are a few User-Agent and Accept headers I've been able to 
gather.

- Firefox 2 on XP:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.20) 
Gecko/20081217 Firefox/2.0.0.20 (.NET CLR 3.5.30729)
Accept: 
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

(I was surprised to see that this one doesn't seem to be recognised as 
'agentName=Firefox' but 'Mozilla'; here are the attributes: 
{agentName=Mozilla, osData=Windows NT 5.1; en-GB; rv:1.8.1.20) 
Gecko/20081217 Firefox/2.0.0.20 (.NET CLR 3.5.30729, agentVersion=5.0, 
agentOs=Windows}.)


- Browser in the GWT Eclipse plugin:
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) 
Gecko/20050920
Accept: 
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

- iPod Touch (FW 2.2.1, not the latest):
User-Agent: Mozilla/5.0 (iPod; U; CPU iPhone OS 2_2_1 like Mac OS X; 
en-us) AppleWebKit/525.18.1 (KHTML, like Gecko) Version/3.1.1 
Mobile/5H11 Safari/525.20
Accept: 
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

- MSIE 8 on XP:
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; 
Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1; .NET CLR 
3.0.4506.2152; .NET CLR 3.5.30729)

- Safari 4 on XP:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) 
AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Safari/530.17
Accept: 
application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

- Safari 4 on OSX:
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us) 
AppleWebKit/530.18 (KHTML, like Gecko) Version/4.0.1 Safari/530.18
Accept: 
application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Thierry Boileau wrote:
 Hi Bruce,
 
 can you send us the content of the user-agent header? We will complete 
 the default agent.properties file.
 
 best regards,
 Thierry Boileau
 Hi guys,

 I'm setting up a restlet app at the moment, and I'd like to set it up so 
 that if a user uses a browser to access a resource, he gets given a nicely 
 formatted HTML page, but if he separately asks for XML or JSON he gets a 
 machine parsable response.  Its all working well on Firefox, but I'm having 
 some issues getting it working on Safari 4.

 It looks like the problem is the Accept: header that is being sent in by 
 Safari.  Its 

 application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

 This causes the content negotiation process to favor xml as an output over 
 html, as html has a priority of 0.9.  I tried xhtml, which has the same 
 priority as xml, but it looks like it still chooses xml (presumably it is 
 random which response you get if they have the same priority).

 Is there a way I can override Safari's preferences?  I know that it is 
 asking to have xml as the highest priority, but frankly I think that is 
 wrong.

 Any suggestions that you can give would be appreciated.

 Bruce.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2365031