[OASIS Issue Tracker] Commented: (ODATA-527) Relative URLs in OData and the ability to put OData services 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=34756#action_34756 ] 

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

Ok, think I got confused by the sample stating you'd have a Host and a OData-BasePath header, Host being a header on the request and not the response I suppose I presumed that OData-BasePath came in with the request too. So if I understand correctly you are proposing that, effectively instead of the Content-Location we'd have a OData-BasePath header on the response which:
- if not specified is the service root
- otherwise specifies the path, relative to the host, at which all services are, ultimately, rooted as well as being the base for all the relative URLs in the response.

Question then being, how would a client know what relative URLs to use in a request, which it'll have to if the service is proxied (which the client doesn't need to know about), when posting a request to a service with linked services? How would it even know what the service root for such service(s) is even if it were aware of the 'base-path'? For example, the one I'm trying to solve (without the extra cloud 'proxy' layer):

Client connects to: https://host:port/pmhub/services/tm1/planning1

Where my planning1 tm1 server runs on same or other host and is addressed as: https://host:port/api/v1

Where api/v1 is my service root on that particular host for the planning1 instance of my OData provider (running multiple of those providers on different ports).

On top of that, for reasons I mentioned in my original e-mail/comment, I think we have to amend the format specific rules at least for the JSON format, as relative URLs ought to be always relative to the service root, which they effectively are in minimal and full metadata but not for none (and that shouldn't influence it IMHO) nor would Content-Location relative or request relative work as we've established already.


> Relative URLs in OData and the ability to put OData services 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.
> Interpreting URLs relative to the Content-Location header or the request URL doesn'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. Especially with containment or several function segments this can become painful.

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