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: 
Within a message the format-specific rules (xml:base, odata.context, odata.type) for resolving relative URLs apply.

Define a special header OData-BasePath that, if present, is the base path for URLs that are still relative after applying the format-specific rules. This header can be easily rewritten by proxies.

The host and port are contained in the standard Host header, so these can be rewritten separately.

If the OData-BasePath header is not present, the service root is used as the base path.

The header is intentionally named BasePath to support multi-service scenarios where several interrelated services use a common path prefix, e.g.

   http://machine:40/odata/HR.svc
   http://machine:40/odata/Procurement.svc

This allows e.g. the Procurement service to contain navigation links of the form

   HR.svc/Employees(123)

that then are combined with 

   Host: machine:40
   OData-BasePath: /odata/

Two possible special cases are
- the base path is a single / meaning that the services just share the same logical host
- the base path is the service root path
The latter is the natural choice for isolated services not linking to other services,  so this is the default if no header is present.

Services will specify the header if they have to produce links to other services.

Clients need not specify this header at all. 

  was:
Within a message the format-specific rules (xml:base, odata.context, odata.type) for resolving relative URLs apply.

Define a special header OData-BasePath that, if present, is the base path for URLs that are still relative after applying the format-specific rules. This header can be easily rewritten by proxies.

The host and port are contained in the standard Host header, so these can be rewritten separately.

If the OData-BasePath header is not present, the service root is used as the base path.

The header is intentionally named BasePath to support multi-service scenarios where several interrelated services use a common path prefix, e.g.

   http://machine:port/odata/HR.svc
   http://machine:port/odata/Procurement.svc

This allows e.g. the Procurement service to contain navigation links of the form

   HR.svc/Employees(123)

that then are combined with 

   Host: machine:port
   OData-BasePath: /odata


V4 adds cross-service navigation, i.e. services linking to other services. For us this will become the standard scenario: not just a single service, but families of interconnected services. 

So any solution for simplifying proxy scenarios has to support cross-service links.

> 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

        


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