-
Notifications
You must be signed in to change notification settings - Fork 28
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
https://w3id.org/xapi/profiles#1.0 redirection does not work #254
Comments
@imartinezortiz , this is the perfect place to bring things up. We've spun up a working group that meets every other Tuesday (including next Tuesday) and will address the issue then, if not before. If you aren't already part of it, let me know if you want an invitation. Thanks! |
Hi Andy, I'm already part of the WG. Just taking notes for today's (alignment subgroup) and for next week meeting. See you next week. |
Hey Ivan, I thought that was you and did check the email afterwards. Sounds great! |
Per the 5/3/2022 meeting, @imartinezortiz has already tested the above fix. This was brought on by the xAPI Profile Server being the redirect from the w3ids. Whereas the vocab server successfully handled these, the xAPI Profile Server lacks some capability but also some rules have not been updated. @andyjohnson will submit a Pull Request once a certain threshold/timing has been reached to the w3id repository maintainers. |
Sorry if this is not the proper location to submit the issue, but I didn't found a fork of https://github.com/perma-id/w3id.org/ in the adlnet org to submit there.
Reviewing the xAPI profile structure: profile properties section of the spec I realized that following the link https://w3id.org/xapi/profiles#1.0 included in the
conformsTo
attribute, does not redirect to https://adlnet.github.io/xapi-profiles/#1.0, but instead shows the empty content of https://w3id.org/xapi/profiles directory.The problems seems to be related to https://github.com/perma-id/w3id.org/blob/master/xapi/profiles/.htaccess#L34. My understanding is that the hash / fragment part is never seen by the server so the pattern never matches. I've tried locally the following directive and it works:
The text was updated successfully, but these errors were encountered: