OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Updated: (ODATA-527) Relative URLs in OData and the ability to put OData services behind an HTTP proxy


     [ http://tools.oasis-open.org/issues/browse/ODATA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralf Handl updated ODATA-527:
-----------------------------

    Proposal: 
Protocol
The metadata URL MUST be the service root URL followed by /$metadata.

Relative URLs are ultimately relative to the request URL
Within a message the format-specific rules (xml:base, odata.context, odata.type) for resolving relative URLs apply. 

Services MUST provide URLs relative to the service root whenever possible.

Clients MUST provide URLs relative to the service root in the $id system query option in requests for removing references to an entity whenever possible.

Clients MUST provide request URLs within batch requests relative to the request URL whenever possible (i.e. same scheme, host, and port as the request URL). This means relative to the service root because we fix /$batch at the service root.


JSON
The outermost context URL is relative to the request URL, setting the base for all other relative URLs to the service root.
This is also the case if the outermost context URL is not specified, e.g. in metadata=none responses and in requests.
So the service root is effectively the base for all relative URLs other than the context URL in the outermost object.

Nested context URLs are relative to the next outer context URL.

All other relative URLs are relative to the next context URL.


Atom
Replace second and third paragraph with:

If no xml:base attribute is present in the context of a relative reference, relative URLs are relative to the request URL.
This also applies to relative URLs in the xml:base attribute.

  was:
Protocol
The metadata URL MUST be the service root URL followed by /$metadata.

Relative URLs are ultimately relative to the request URL
Within a message the format-specific rules (xml:base, odata.context, odata.type) for resolving relative URLs apply. 

Clients MUST provide URLs relative to the service root in the $id system query option in requests for removing references to an entity whenever possible.

Clients MUST provide request URLs within batch requests relative to the request URL whenever possible (i.e. same scheme, host, and port as the request URL). This means relative to the service root because we fix /$batch at the service root.


JSON
The outermost context URL is relative to the request URL, setting the base for all other relative URLs to the service root.
This is also the case if the outermost context URL is not specified, e.g. in metadata=none responses and in requests.
So the service root is effectively the base for all relative URLs other than the context URL in the outermost object.

Nested context URLs are relative to the next outer context URL.

All other relative URLs are relative to the next context URL.


Atom
Replace second and third paragraph with:

If no xml:base attribute is present in the context of a relative reference, relative URLs are relative to the request URL.
This also applies to relative URLs in the xml:base attribute.


> 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
>            Priority: Blocker
>             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

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]