-
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?
Conversation
} | ||
} | ||
|
||
private ODataResource CreateResource1(Uri id = null) |
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.
Can we consolidate the CreateResource# into one method? #Closed
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.
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 comment
The 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 comment
The 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
Added inline comment.
In reply to: 202220739 [](ancestors = 202220739)
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.
Thanks for looking into this! #ByDesign
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.
Left some small comments.
38c09ec
to
3319a96
Compare
3319a96
to
c92c1b8
Compare
c92c1b8
to
e483895
Compare
/// <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 comment
The 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 comment
The 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
/// This URI will be used in ATOM format only, it would be overridden by <xml:base /> element in ATOM payload. |
In reply to: 203896122 [](ancestors = 203896122)
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.
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 comment
The 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)
Does this fix the issue with OData Client? I don't see where RelativeUrl gets set in MessageWriterSettings. Could it use BaseUri instead? #ByDesign |
/// <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. |
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.
a top-level [](start = 57, length = 12)
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)
I believe the the ODataJsonLightContextUriParser.Parse() is invoked when client is reading the payload using reader settings. This change is to fix the issue of reading payload with relative url by, form example, OData Client; not the writing part. In reply to: 406439921 [](ancestors = 406439921) |
Sorry, I meant MessageReaderSettings. How/where does RequestUri get set when using ODataClient to read a result with relative URLs? In reply to: 406729387 [](ancestors = 406729387,406439921) |
This fix appears to be specific to the contextUrl. how do we resolve relative urls in nextLinks, edit/readLinks, mediaLInks, relationshipLinks, etc.? #Resolved |
See RelativeUriReaderTests.cs L249 as an example. In reply to: 407874612 [](ancestors = 407874612,406729387,406439921) |
This issue is for relative contextUrl only, not including other relative urls. In reply to: 407879722 [](ancestors = 407879722) |
@mikepizzo Please see replies above. Not sure why my replies to your comments seem to be dislocated on the web page. If you can open CodeFlow, you can see that they are aligned much better there. #Resolved |
🕐 |
I'm also affected by this issue, is there any way I can help unblocking this pull request? |
f9519fd
to
14a4b12
Compare
Anything we can help out on with this PR @mikepizzo? |
Hi guys, I face the same issue, is there any progress? Thanks a lot! |
Issues
This pull request fixes issue #1208.
Description
Fix error for relative context Uri resolution using the request uri passed in from the reader settings, applying similar logic from ODL-6.x branch.
Checklist (Uncheck if it is not completed)
Additional work necessary
If documentation update is needed, please add "Docs Needed" label to the issue and provide details about the required document change in the issue.