[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=34778#action_34778 ] 

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

Making having $metadata at the root of the service a must implicitly makes all relative URLs relative to the service root, that's great. However for odata.metadata=none we say that we SHOULD NOT include the odata.context annotation in which case we can't have the same relative URLs unless we include it anyway (it's a 'should not' so we'll likely end up having to do it).

However for the odata.metadata=none case one presumes already that the client has out of band information about the service anyway so we were wondering if we couldn't create a level playing field here by:
- having relative context URLs be relative to the request URL (context URLs being relative to each other is deemed kind of odd and would only add any value if one fully qualifies a context URL already anyway in which case there is no reason why not to fully qualify the supposedly relative one to the fully qualified one as well).
- having all other relative URLs be relative to the context URL and, if no context URL is provided, which would be only in the case of odata.metadata=none for responses and for requests that don't include a odata.context, have these URLs be relative to the service root (instead of the request URL)

This would also apply to $id, having it relative to the request is the request is not referring to a resource at the service root only implies one needs to add a bunch of additional ../ segments to get to service root again. The only exception would be in cases were there is a reference to an entity that would also be contained by the same object - which is a kind of odd/exceptional case anyway).

With this minor adjustment we'd always have, with the exception of context URLs, all URLs (read: dereferenceable id's etc.) relative to the root and one would never have to rework any of the relative URLs with again the exception of context URLs.

> 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 necessary to place an OData producer behind a (reverse) proxy. 
> HTTP proxies will alter request URLs. They typically change:
> - the scheme (http or https)
> - the host
> - the port
> They can change the path, typically by exchanging a prefix portion.
> They also can add, remove, or modify HTTP request and response headers.
> They cannot alter message bodies without knowledge beyond HTTP, in our case knowledge of the OData formats
> - CSDL
> - Atom
> - JSON
> - anything we might want to add in the future
> So message bodies should only contain URLs that need not be altered by HTTP proxies.
> This affects request bodies created by OData consumers and response bodies created by OData producers.
> Two typical candidates for such "proxy-safe" URLs are
> - absolute URLs outside of the domain shielded by the proxy
> - relative URLs that are relative to something the proxy can easily alter
> In addition resolution of relative URLs should be possible with the information contained in the request-response message pair and no out-of-band knowledge beyond the OData specifications. Note that the service root is out-of-band knowledge: it cannot be calculated from the context URL which is based on the metadata URL, and the service root URL is not a specified part of the metadata document. 
> Problems with the current rules for relative URLs
> - Content-Location header: this header is only available in responses. Also it has special meaning if it deviates from the request URL, so having it in the resolution chain only adds problems and does not add any value
> - Batch requests allow three formats for request URLs in the batch body, and the relative format is mentioned last.

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