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] Commented: (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:comment-tabpanel&focusedCommentId=34737#action_34737 ] 

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

I've discussed this with the team and, as usual, they had some concerns.

First up, as per the amended description, you wouldn't in this solution go to the actual service root but, based on the example given in the proposal, one level up from that, which they feel would be very strange and unnatural.

As for the proposed header, there is kind of a presumption in the proposal that all services would be addressable effectively as 'siblings' under a common root path. They felt that was a very specific use case. Also that would imply that the response generated would differ, obviously, based on what the root was and that the service would need to know, or make assumptions based on the fact that this OData-BasePath existed, as to what additionally to inject into the, otherwise, relative URLs.

We also feel its unnatural that a, generic presumably, client would, up-front, need to be aware of the fact it 1, would need to specify this header and 2, that it is only part of the actual service root to interrogate. I.o.w. it sounds like this would only work for clients that have out-of-band knowledge, something we feel should not be part of the standard.

We don't have a fully worked out alternative approach but we were thinking along the lines of
 - not requiring a client needing to be aware of anything but presuming it would be fine, if need be, that proxies would be aware and as such structures
 - optionally, if we want everything to be relative, potentially have an odata service itself be the 'proxy' for odata services, by which these services themselves would become resources of the services as well, allowing all URLs once again always to be relative to the service root of the service.



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