Uploaded image for project: 'OASIS Open Data Protocol (OData) TC'
  1. OASIS Open Data Protocol (OData) TC
  2. ODATA-527

Relative URLs in OData and the ability to put OData services behind an HTTP proxy

    XMLWordPrintable

    Details

    • Proposal:
      Hide

      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 behind proxies should provide relative URLs using the format-specific rules 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.

      The outermost odata.type URL is relative to the outermost context URL.
      Nested odata.type URLs are relative to the next outer odata.type.

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

      Atom
      Relative URLs are always relative to the next xml:base.

      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.

      Accepted: https://www.oasis-open.org/committees/download.php/50924/odata-meeting-55_on-20131003-minutes.html#odata-527

      Show
      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 behind proxies should provide relative URLs using the format-specific rules 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. The outermost odata.type URL is relative to the outermost context URL. Nested odata.type URLs are relative to the next outer odata.type. All other relative URLs are relative to the next context URL. Atom Relative URLs are always relative to the next xml:base. 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. Accepted: https://www.oasis-open.org/committees/download.php/50924/odata-meeting-55_on-20131003-minutes.html#odata-527
    • Resolution:
      Hide

      https://www.oasis-open.org/committees/download.php/50900/odata-v4.0-wd04-part1-protocol-2013-10-03.docx

      https://www.oasis-open.org/committees/download.php/50901/odata-atom-format-v4.0-wd04-2013-10-03.docx

      https://www.oasis-open.org/committees/download.php/50899/odata-json-format-v4.0-wd04-2013-10-03.docx

      Accepted: https://www.oasis-open.org/committees/download.php/50924/odata-meeting-55_on-20131003-minutes.html#odata-5

      Show
      https://www.oasis-open.org/committees/download.php/50900/odata-v4.0-wd04-part1-protocol-2013-10-03.docx https://www.oasis-open.org/committees/download.php/50901/odata-atom-format-v4.0-wd04-2013-10-03.docx https://www.oasis-open.org/committees/download.php/50899/odata-json-format-v4.0-wd04-2013-10-03.docx Accepted: https://www.oasis-open.org/committees/download.php/50924/odata-meeting-55_on-20131003-minutes.html#odata-5

      Description

      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.

        Attachments

          Activity

            People

            • Assignee:
              handl Ralf Handl
              Reporter:
              handl Ralf Handl
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: