-
Notifications
You must be signed in to change notification settings - Fork 172
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
Proper origin terminology, references, and setting of callerOrigin #202
Conversation
<!-- , <a>opaque origin</a>, --> | ||
|
||
: HTML | ||
:: The concepts of <a link-for='web'>current settings object</a>, |given value|, <a link-for='web'>opaque origin</a>, |
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.
You can remove the for='web' everywhere now. It was only required for disambiguation before because there were two definitions of "origin" (one here, one as a member of ClientData). So the link-for helped bikeshed figure out which one we were talking about.
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.
hm, well, given this branch's current state, it needs the link-for='web' to compile. perhaps we can clean that up after merging all these PRs to master?
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.
WFM
terminate this algorithm. | ||
Otherwise, apply the <a link-for='web'>relaxing the same-origin restriction</a> "setting" algorithm using |callerOrigin| as | ||
the |given value|. | ||
If no errors are thrown, then derive the RP ID from |callerOrigin| by computing the |
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.
If no errors are thrown, we should take the value of host
computed by the algorithm, right? This sounds redundant, as if we need to compute eTLD again independently.
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.
oh, so I didn't touch the text beyond the "derive the RP ID..." because PR #198 is altering it. should we (1) try to clean up before merging these PRs, or (2) merge one to master, the merge master to the un-merged branch, clean-up, and then merge the latter?
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 see. Yeah, I would do (2).
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.
ok, which PR merge first?
terminate this algorithm. | ||
Otherwise, apply the <a link-for='web'>relaxing the same-origin restriction</a> "setting" algorithm using |callerOrigin| as | ||
the |given value|. | ||
If no errors are thrown, then derive the RP ID from |callerOrigin| by computing the |
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.
See above.
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.
ditto :)
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.
ditto :)
This resolves several issues regarding "origin" and references into the HTML (html51) spec. It needs to be composed with #198 to fully make sense.