Skip to content
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

Merged
merged 5 commits into from
Sep 20, 2016

Conversation

equalsJeffH
Copy link
Contributor

This resolves several issues regarding "origin" and references into the HTML (html51) spec. It needs to be composed with #198 to fully make sense.

@equalsJeffH equalsJeffH added this to the WD-02 milestone Sep 16, 2016
@equalsJeffH equalsJeffH self-assigned this Sep 16, 2016
<!-- , <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>,
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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
Copy link
Contributor

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.

Copy link
Contributor Author

@equalsJeffH equalsJeffH Sep 16, 2016

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?

Copy link
Contributor

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).

Copy link
Contributor Author

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See above.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants