[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=34797#action_34797 ] 

Michael Pizzo commented on ODATA-527:
-------------------------------------

i'm not sure why it's odd (or a problem) to have context urls be relative to their parent context url.

If the root context url relative to the request URL transitively makes all nested context urls relative to the same url unless you are traversing a service, in which case you want to be able to say that the subsequent nested urls are relative to a different base.

It's particularly important for the schema.org case (and scenarios like it) that the types be defined in a separate service (not relative to the service root) and we don't have to make them *all* absolute for this case.

That's okay, because we say that the urls that represent the types are relative to the parent type, and the root type is relative to the context url, so if you use all relative references you are still okay.

> 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