RE: Disabling the TunnelService
Hi all, I prefer leaving the originalRef absolutely untouched by the routing process and therefore not setting/syncing its baseRef property. I think it will help to separate its role relatively to resourceRef. Here are the new Javadocs for the Request#getResourceRef() method: /** * Returns the reference of the target resource. This reference is especially * important during routing, dispatching and resource finding. During such * processing, its base reference is constantly updated to reflect the * reference of the parent Restlet or resource and the remaining part of the * URI that must be routed or analyzed. * * If you need to get the URI reference originally requested by the client, * then you should use the [EMAIL PROTECTED] #getOriginalRef()} method instead. Also, * note that beside the update of its base property, the resource reference * can be modified during the request processing. * * For example, the [EMAIL PROTECTED] TunnelService} associated to an application can * extract some special extensions or query parameters and replace them by * semantically equivalent properties on the request object. Therefore, the * resource reference can become different from the original reference. * * Finally, when sending out requests via a dispatcher such as * [EMAIL PROTECTED] Context#getClientDispatcher()} or * [EMAIL PROTECTED] Context#getServerDispatcher()}, if the reference contains URI * template variables, those variables are automatically resolved using the * request's attributes. * * @return The reference of the target resource. * @see #getOriginalRef() */ Changes committed in SVN trunk. Best regards, Jerome -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Envoyé : mercredi 21 mai 2008 22:32 À : discuss@restlet.tigris.org Objet : Re: Disabling the TunnelService Hi, Alex Milowski wrote: Would Request.originalRef still have getRemainingPart() returning the unmatched portion? For this I propose to create a new Reference instance for every call with the baseRef of the updated reference. So they are ever syncronized. best regards Stephan
RE: Disabling the TunnelService
Hi Alex, Thanks for sharing the Atomojo usage details. The TunnelService has been turned on since 1.0 and nobody complained (yet) about the default query parameters (method, charset, encoding, language and media). If needed they can be renamed by the user. Also note that when they are matched, those query parameters are removed from the resourceRef property. So the current behavior regarding extensions was not really a fundamental change :-), but it's visibility/impact was greater than for query parameters and gave you this feeling. It definitely indicates that there is a lack of documentation regarding the semantics of the resourceRef property. Currently, when the extensions are touched, the TunnelService puts the original reference in a org.restlet.TunnelService.originalRef attribute of the request. But this is not very easy to use. So, I propose to replace this attribute by a more explicit Request.originalRef property and clearer Javadocs regarding Request.resourceRef whit cross-refs with originalRef. Would that work for you? Best regards, Jerome -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Alex Milowski Envoyé : lundi 19 mai 2008 22:19 À : discuss@restlet.tigris.org Objet : Re: Disabling the TunnelService On Mon, May 19, 2008 at 1:31 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Alex, Like Thierry, I have just checked the code again and in trunk the extensions tunnel feature is now off by default. The idea behind this feature is to have a very simple way for a user to specify, for any resource hosted within an application, which representation he wants. The standard way is to use the Accept header (hard with browsers and not very intuitive), the other way is to use the ?media=xml query parameter which is processed by the TunnelService by default and converted into the equivalent Accept header info (the query parameter is then removed from the 'resourceRef' to make this feature transparent to the application resources). I understand this is a good feature but many applications may find intruding on the resource reference a problem. That is, what if the media query parameter is already used. Now, if you want such a feature... having to just make a single call to turn it on is probably really useful. Now with the extensions tunneling, the user can just append .xml to the last segment and have an effect similar to using an Accept: text/xml header, with no change to the application logic. I would be interested to understand why/how it breaks your URI processing logic, but my feeling is that in 90% of cases, it will be a very convenient feature. BTW, we already support something similar for the Directory class. In atomojo, the extension is a choice made by the user using the atom publishing protocol. They send a slug header to control the actual file name. As such, the extension could be .foo or .myrandomxmldocument for text/xml and not .xml. That means that I need to honor the original requested file name in the last segment and attempt to find it in the storage. I have all the requested information for formulating the response and setting the media type in an database external to the actual storage vehicle. In the case of the tunnel service, what doesn't make sense to me is that it seems like the extension information just disappeared. It wasn't that it was placed in another facet of the Reference instance and I had to get at it using getExtensions(). It just completely vanished. As such, I could not reconstruct the original last segment. Also, if you want to have a common configuration policy across all your applications (for example to disable all services and associated filters), then I suggest that you use a BaseApplication class extending o.r.Application. As a policy, I turn off the TunnelService explicitly in all my applications because what tasks it performs do not help me. I do feel your pain regarding the unexpected changes to your URIs and logic, and I apologize for the time lost in figuring out what happened. I think that Rob's proposition to add a requestedRef property and to clarify resourceRef Javadocs is a good way to clarify the actual intent. No need to apologize. I was very surprised and frustrated with what seemed like a very fundamental change. In this case, I do rely upon getResourceRef() related processing. I do want getRemainingPart() to give me the matching portion minus the path that go to my application via routing. It is just that the tunnel service gets inserted automatically that was surprising to me. --Alex Milowski
RE: Disabling the TunnelService
Hi Rob, Thanks for perfectly summarizing the situation. I like your proposition of exposing a new property. I just propose to name it originalRef instead as it is already relative to the Request class, implicitely meaning originally requested reference :-) Best regards, Jerome _ De : Rob Heittman [mailto:[EMAIL PROTECTED] Envoyé : vendredi 16 mai 2008 23:46 À : discuss@restlet.tigris.org Objet : Re: Disabling the TunnelService I feel like part of the debate results from the contract of Request.getResourceRef() being unclear. There seem to be at least two differences of opinion in common circulation: 1) - getResourceRef() is returning the reference of the resource *as originally requested* by the client. OR 2) - getResourceRef() is returning the reference of the resource *after processing* by filters and services in the Restlet plumbing. In addition, because we use RIAP a lot, we also have a 3), the reference of the resource as seen from the external client which triggered some chain of internal requests. This is probably a boundary case. I have seen fairly experienced Restlet users try to use getResourceRef().getBaseRef() and such to try to get at one of these meanings when it seems another of the meanings is being used. In point of fact, the first two cases are just ambiguous. My suggestion would be to canonize meaning 2) for getResourceRef() -- as this seems to be what it is now anyway -- and to expose a new getRequestedRef() which returns the original client-requested reference in a way that is fairly difficult to mutate by accident. Those of us who ABSOLUTELY NEVER want a mutated reference in a certain context can then be assured of getting it. - R
Re: Disabling the TunnelService
On Wed, May 21, 2008 at 3:38 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Alex, Thanks for sharing the Atomojo usage details. The TunnelService has been turned on since 1.0 and nobody complained (yet) about the default query parameters (method, charset, encoding, language and media). If needed they can be renamed by the user. Also note that when they are matched, those query parameters are removed from the resourceRef property. So the current behavior regarding extensions was not really a fundamental change :-), but it's visibility/impact was greater than for query parameters and gave you this feeling. It definitely indicates that there is a lack of documentation regarding the semantics of the resourceRef property. Currently, when the extensions are touched, the TunnelService puts the original reference in a org.restlet.TunnelService.originalRef attribute of the request. But this is not very easy to use. So, I propose to replace this attribute by a more explicit Request.originalRef property and clearer Javadocs regarding Request.resourceRef whit cross-refs with originalRef. Would that work for you? Would Request.originalRef still have getRemainingPart() returning the unmatched portion? Either way, this works for me because I can just turn it off for my uses (which is what I did) and everything works as expected. --Alex Milowski
Re: Disabling the TunnelService
Hi, Alex Milowski wrote: Would Request.originalRef still have getRemainingPart() returning the unmatched portion? For this I propose to create a new Reference instance for every call with the baseRef of the updated reference. So they are ever syncronized. best regards Stephan
Re: Disabling the TunnelService
Hi all, The only thing that is done by default is the update of the user preferences based on query parameters (method and metadata). best regards, Thierry Boileau Hi Alex, If you enable the tunnel service, then I could see (based on whatever it is suppose to do), the URI changing. Could you give more details? best regards Stephan
Re: Disabling the TunnelService
On Mon, May 19, 2008 at 1:31 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Alex, Like Thierry, I have just checked the code again and in trunk the extensions tunnel feature is now off by default. The idea behind this feature is to have a very simple way for a user to specify, for any resource hosted within an application, which representation he wants. The standard way is to use the Accept header (hard with browsers and not very intuitive), the other way is to use the ?media=xml query parameter which is processed by the TunnelService by default and converted into the equivalent Accept header info (the query parameter is then removed from the 'resourceRef' to make this feature transparent to the application resources). I understand this is a good feature but many applications may find intruding on the resource reference a problem. That is, what if the media query parameter is already used. Now, if you want such a feature... having to just make a single call to turn it on is probably really useful. Now with the extensions tunneling, the user can just append .xml to the last segment and have an effect similar to using an Accept: text/xml header, with no change to the application logic. I would be interested to understand why/how it breaks your URI processing logic, but my feeling is that in 90% of cases, it will be a very convenient feature. BTW, we already support something similar for the Directory class. In atomojo, the extension is a choice made by the user using the atom publishing protocol. They send a slug header to control the actual file name. As such, the extension could be .foo or .myrandomxmldocument for text/xml and not .xml. That means that I need to honor the original requested file name in the last segment and attempt to find it in the storage. I have all the requested information for formulating the response and setting the media type in an database external to the actual storage vehicle. In the case of the tunnel service, what doesn't make sense to me is that it seems like the extension information just disappeared. It wasn't that it was placed in another facet of the Reference instance and I had to get at it using getExtensions(). It just completely vanished. As such, I could not reconstruct the original last segment. Also, if you want to have a common configuration policy across all your applications (for example to disable all services and associated filters), then I suggest that you use a BaseApplication class extending o.r.Application. As a policy, I turn off the TunnelService explicitly in all my applications because what tasks it performs do not help me. I do feel your pain regarding the unexpected changes to your URIs and logic, and I apologize for the time lost in figuring out what happened. I think that Rob's proposition to add a requestedRef property and to clarify resourceRef Javadocs is a good way to clarify the actual intent. No need to apologize. I was very surprised and frustrated with what seemed like a very fundamental change. In this case, I do rely upon getResourceRef() related processing. I do want getRemainingPart() to give me the matching portion minus the path that go to my application via routing. It is just that the tunnel service gets inserted automatically that was surprising to me. --Alex Milowski
Re: Disabling the TunnelService
Hi Alex, If you enable the tunnel service, then I could see (based on whatever it is suppose to do), the URI changing. Could you give more details? best regards Stephan
Disabling the TunnelService
I now strongly believe that the TunnelService needs to be off by default. I've had to go into *every* single class that extends Application and add this line to my constructor: getTunnelService().setEnabled(false); All of my code is now breaking wherever there is a resource with an extension because getRemainingPart() now returns the path minus the extension in the last segment. This magic mucking around with the resource reference has cause me no end of troubles. I'm not really certain why this service needs to be on by default but I can say with 100% certainty that I don't need it on for *any* of my applications that use Restlet. I just want the resource reference as requested by the client. If we apply the policy of least surprise to this, you would think that advanced features for variants/etc. would need to be enabled so that, at minimum, without changing any settings, you just get the URL path for the resource upon which the request was made. That dictates that: * unnecessary filters should be off by default * features like the tunnel service should be required to be turned on * the resource reference should remain the same regardless of whether such filters are enabled. --Alex Milowski
Re: Disabling the TunnelService
Hi Alex, I now strongly believe that the TunnelService needs to be off by default. do you used the most actual version? The extension tunnel is off by default now. * the resource reference should remain the same regardless of whether such filters are enabled. IMO no. It is the sense of it, to hide it, if the client used a virtual file extension or a query parameter for content negotiation, e.g. because no other way for it is possible or complicate to reach. As said, the extension tunnel is off by default now, so if you don't switch it on, it will not change your URI. If yes, than it is bug. Let us know. best regards Stephan
