[OASIS Issue Tracker] Commented: (ODATA-527) Relative URLs in OData and the ability to put an OData service end-point behind an HTTP proxy

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/ODATA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=34733#action_34733 ] 

Hubert Heijkers commented on ODATA-527:
---------------------------------------

My e-mail that lead to this ticked:

We've been looking at putting my TM1 OData service 'behind a proxy' making it appear as part of a larger system which in turn might actually be running as a service in a larger cloud solution (another proxy effectively). To only way we can think of to make this work, without having any of the proxies being aware of the fact that this is a, particular, OData service they are, ultimately, fronting, is to make all URLs in our requests and responses relative. Oh, and note, we are only looking at JSON format, not taking anything specific Atom into account. 

There is a number of places in the specification we talk about relative URLs. 

In section 4.3 of the JSON format. Ralf and I already discussed and agreed that, even though it doesn't explicitly state so, context URLs, can be relative but then presumably can only be so if the resource we were after was at the root or if we included a Content-Location that represented the service root. The latter however is odd because if the request wasn't going after a resource at the root level you could argue that the Content-Location, if included, would represent the location of the resource being represented in the response which then most likely wouldn't be rooted at the service root either (typically if all URLs are according to the spec right). Also Content-Location is only specified for GET. 

In 4.5.7, pertaining to odata.id, we mention that the URL may be relative as well but we don't describe to what. Presuming we would follow the rules laid out in 4.3 it would typically be relative to the context URL, as context URL MUST be included in both minimal and full metadata which brings me back to making context URL relative again. 

Ironically in 6, Entity, we specify that the context URL can be used in requests only as a base for relative URLs but, apart from now the client needing to know how to construct correct context URLs, context URLs by design point to the service root, but the same problem occurs with proxying as one can't know how this fully qualified URL should look like to the service and using a relative URL here defeats the purpose. 

Bind operations, 8.5, have effectively the same issue once again. Also here we say they may be relative, presumably following the same rules, but, other then in resources which are rooted at the service root as well, you'd want to be able to specify they would be relative to the service root and not the request. 

With Ralf I already discussed an issue around $id as well. $id specifies the 'id' of an entity by its fully qualified URL or, presumably like odata.id could be, a relative URL. In case of a relative URL a GET is fine as the $entity resource, which one would use the $id in combination with, is rooted at the service root. However for deleting it from a navigation property it would become relative to the resource containing the navigation property so that wouldn't work any longer. 

So, since we are creating a CS2 as well;-), maybe we could improve all this dealing with relative URLs in a way that we can make it work in case were we proxy the whole service. The one stable piece of information that the client holds about a service is the URL it uses as the service root. So I suppose my question is more along the lines off; couldn't relative URLs in OData not always be relative to the service root? I realize that that might be a hard sell however so short of that is there something we could introduce, an OData header for example, for which we'd define that whatever we specified for it that that would represent the base relative to the service root. 

One more piece of information, part of my use case, we have a transfer capability which effectively takes a response from one server instance and then, preferably without changing anything, POSTs that response to another service. Needless to say that all URLs in that case need to be relative as well (and obviously the request would need to be very well formed for that to work). 

Any thoughts? Do you guys want to discuss further or should I go ahead and create a Jira ticket? 

BTW wouldn't it be nice if we'd everywhere would have the same relative canonical URL identifying an entity? 

> Relative URLs in OData and the ability to put an OData service end-point behind an HTTP proxy
> ---------------------------------------------------------------------------------------------
>
>                 Key: ODATA-527
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-527
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData ATOM Format , OData CSDL, OData JSON Format, OData Protocol 
>    Affects Versions: V4.0_CS01
>         Environment: [Proposed]
>            Reporter: Ralf Handl
>             Fix For: V4.0_CSD03
>
>
> It is often desirable to place an OData producer behind a (reverse) proxy. 
> This works best if all URLs in requests and responses are relative, so proxies don't have to touch the message bodies.
> Established mechanisms of interpreting URLs relative to the Content-Location header or the request URL don't work well with OData's URL conventions, which are constructed relative to the service root, so URLs starting relative to an entity would have to add ../ segments to go "down" to the service root and then "up" into the related entities. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira