> If you have time to help with the RFE, maybe by providing a patch, it could > still go into the upcoming 1.1 release :)
I posted a fairly non-invasive patch and additional class to the RFE. I'm sure you could improve upon it. http://restlet.tigris.org/issues/show_bug.cgi?id=157 It adds a LoopbackDispatcher class that is aware of both the client and server routers in the component and can loopback certain request roots only if explicitly told to do so by an attribute set in the ComponentContext: List<String> loopbacks = new ArrayList<String>(); loopbacks.add("https://localhost:8443/usrv"); component.getContext().getAttributes().put("loopback.list",loopbacks); This seems to work as one would expect, with the expected performance gain and negligible cost. I explored down the road of attempting to transparently poll server routes before dispatching to any client routes. (If a valid HostRoute attached to the server router could handle the request, prefer it to using a Client.) This doesn't work well, because the host routes are generally greedy, and there is probably a default host that will claim it can handle anything, even things it shouldn't. I suspect that transparently magical loopback behavior is going to cause massive confusion for somebody at some point, especially if their Restlets are running inside a larger container. I even confused myself :-) This explicitly coded approach seems to do what I need it to do, without breaking anything that currently exists ... thoughts? - Rob

