-
Notifications
You must be signed in to change notification settings - Fork 351
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix relative context Uri resolution #1211
base: release-7.x
Are you sure you want to change the base?
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -61,29 +61,35 @@ private ODataJsonLightContextUriParser(IEdmModel model, Uri contextUriFromPayloa | |
/// <param name="model">The model to use when resolving the target of the URI.</param> | ||
/// <param name="contextUriFromPayload">The string value of the odata.metadata annotation read from the payload.</param> | ||
/// <param name="payloadKind">The payload kind we expect the context URI to conform to.</param> | ||
/// <param name="clientCustomTypeResolver">The function of client cuetom type resolver.</param> | ||
/// <param name="clientCustomTypeResolver">The function of client custom type resolver.</param> | ||
/// <param name="needParseFragment">Whether the fragment after $metadata should be parsed, if set to false, only MetadataDocumentUri is parsed.</param> | ||
/// <param name="throwIfMetadataConflict">Whether to throw if a type specified in the ContextUri is not found in metadata.</param> | ||
/// <param name="baseUri">Optional value (with default value of null) of base Uri used for resolving the context url. | ||
/// It should be a non-null value when resolving a top-level relative context Uri. | ||
/// </param> | ||
/// <returns>The result from parsing the context URI.</returns> | ||
internal static ODataJsonLightContextUriParseResult Parse( | ||
IEdmModel model, | ||
string contextUriFromPayload, | ||
ODataPayloadKind payloadKind, | ||
Func<IEdmType, string, IEdmType> clientCustomTypeResolver, | ||
bool needParseFragment, | ||
bool throwIfMetadataConflict = true) | ||
bool throwIfMetadataConflict = true, | ||
Uri baseUri = null) | ||
{ | ||
if (contextUriFromPayload == null) | ||
{ | ||
throw new ODataException(ODataErrorStrings.ODataJsonLightContextUriParser_NullMetadataDocumentUri); | ||
} | ||
|
||
// Create an absolute URI from the payload string | ||
// TODO: Support relative context uri and resolving other relative uris | ||
// Create an absolute URI from the payload string. | ||
// Uri.TryCreate(Uri, string, out Uri) try creating the Uri directly from specified string value first. | ||
// Resultant Uri is returned directly if it is an absolute Uri; otherwise, baseUri will be used to resolve the relative Uri | ||
// into an absolute Uri. See https://github.com/Microsoft/referencesource/blob/master/System/net/System/UriExt.cs#L315 | ||
Uri contextUri; | ||
if (!Uri.TryCreate(contextUriFromPayload, UriKind.Absolute, out contextUri)) | ||
if (!Uri.TryCreate(baseUri, contextUriFromPayload, out contextUri)) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What will happen if contextUriFromPayload is absolute? I'm reading the API here and it says that the second Uri is relative. #ByDesign There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I believe it might be some doc issue. The actual implementation of Uri.TryCreate(Uri, string, out Uri) first tries to convert the string to absolute uri first if possible; otherwise it tries to use the baseUri to resolve the string representing relative url to get the result. See here: https://github.com/Microsoft/referencesource/blob/master/System/net/System/UriExt.cs#L315 In reply to: 202220739 [](ancestors = 202220739) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for looking into this! #ByDesign |
||
{ | ||
throw new ODataException(ODataErrorStrings.ODataJsonLightContextUriParser_TopLevelContextUrlShouldBeAbsolute(contextUriFromPayload)); | ||
throw new ODataException(ODataErrorStrings.ODataJsonLightContextUriParser_TopLevelContextUrlIsInvalid(contextUriFromPayload)); | ||
} | ||
|
||
ODataJsonLightContextUriParser parser = new ODataJsonLightContextUriParser(model, contextUri); | ||
|
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
|
@@ -176,6 +176,11 @@ public ODataMessageQuotas MessageQuotas | |||
/// </summary> | ||||
public bool ReadUntypedAsString { get; set; } | ||||
|
||||
/// <summary> | ||||
/// Gets or sets current request Uri. | ||||
/// </summary> | ||||
public Uri RequestUri { get; set; } | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What's the relationship between the new RequestUri property and the existing BaseUri property? When does RequestUri get set? Can we just use BaseUri? #ByDesign There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. BaseUri is for Atom format and may be deprecated in the future. See
In reply to: 203896122 [](ancestors = 203896122) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The reason it was to be deprecated was because it was only used in Atom. The reason it was only used in Atom was because we previously didn't support relative URLs in JSON. Now that we support relative URLs in JSON, it seems like we should use this (existing) property, rather than deprecate it and add a new one for the same purpose. In reply to: 204170332 [](ancestors = 204170332,203896122) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I tried using BaseUrl but it fails in multiple cases when the baseurl is the $metadata url, which is common, among other failing cases. In reply to: 205241623 [](ancestors = 205241623,204170332,203896122) |
||||
|
||||
/// <summary> | ||||
/// Func to evaluate whether an annotation should be read or skipped by the reader. The func should return true if the annotation should | ||||
/// be read and false if the annotation should be skipped. A null value indicates that all annotations should be skipped. | ||||
|
@@ -262,6 +267,7 @@ private void CopyFrom(ODataMessageReaderSettings other) | |||
this.validations = other.validations; | ||||
this.ThrowOnDuplicatePropertyNames = other.ThrowOnDuplicatePropertyNames; | ||||
this.ThrowIfTypeConflictsWithMetadata = other.ThrowIfTypeConflictsWithMetadata; | ||||
this.RequestUri = other.RequestUri; | ||||
this.ThrowOnUndeclaredPropertyForNonOpenType = other.ThrowOnUndeclaredPropertyForNonOpenType; | ||||
this.LibraryCompatibility = other.LibraryCompatibility; | ||||
this.Version = other.Version; | ||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why call out "a top level"? Shouldn't it be non-null for resolving any relative context Url? Note that relative nested context urls should be resolved using the parent absolute contextUrl as a base; is this supported? #Resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be any relative context url. Removed "a top level".
In reply to: 203898403 [](ancestors = 203898403)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But changing the comment doesn't change how this works.
If I have a contextUrl nested within another contextUrl "scope", that nested context URL needs to be resolved relative to the outer contextUrl.
For example:
{
"@context" : "http://sampleservice/$externalMetadata#employees",
"value" : [
{
"id":"00001",
"name":"Kathy Smith",
...
"company" :
{
"@context": "#company",
"name":"FirstCompany"
}
}
]
}
or
{
"@context" : "http://sampleservice/externalMetadata#company",
"name":"FirstCompany",
"employees@context": "#employees"
"value" : [
{
"id":"00001",
"name":"Kathy Smith",
...
}
]
}
It's possible (likely) that our stack doesn't support this type of nested contextUrls, but I still want to make sure that we can support relative urls if we add support for nested context Urls in the future.
In reply to: 204168642 [](ancestors = 204168642,203898403)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we are not sure how exactly nested contextUrl is going to be supported, its relative url support should be part of the future task when it comes up. Right?
In reply to: 205245558 [](ancestors = 205245558,204168642,203898403)