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/, 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, 

Step 2. The service then looks into 
org/restlet/service/, 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,


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

- Firefox 2 on XP:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: 
Gecko/20081217 Firefox/ (.NET CLR 3.5.30729)

(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: 
Gecko/20081217 Firefox/ (.NET CLR 3.5.30729, agentVersion=5.0, 

- Browser in the GWT Eclipse plugin:
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) 

- 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

- 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

- 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

Thierry Boileau wrote:
 Hi Bruce,
 can you send us the content of the user-agent header? We will complete 
 the default 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 


 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 

 Any suggestions that you can give would be appreciated.



Architecture question

2009-06-24 Thread Schley Andrew Kutz
I have moved my application from sub-classing Restlets to sub-classing  
Resources and am now relying on annotations to process incoming  
requests (@Get for ex.). However, one of the nice side-effects of  
processing requests with the catch-all handle method is that it allows  
me to have one place to catch exceptions. My question is this: Is  
there a way to catch all exceptions with one method (an onError event  
handler for ex.) so that I can decide what to do with them there?  


Ideally, a code library must be immediately usable by naive  
developers, easily customized by more sophisticated developers, and  
readily extensible by experts. -- L. Stein