-
Notifications
You must be signed in to change notification settings - Fork 129
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
pyld does not inspect Link headers #128
Comments
After reviewing the source, it doesn't seem to be the case that pyld doesn't inspect
Why require JSON repsonses if the
|
The Link handling code is in the document loaders right below where that json() call happens. Quite possible that code hadn't been properly tested before. If someone has time to refactor that code to handle Link header in the proper order, that would be great. |
@davidlehn I'm trying to learn how the tests are put together, to get a clear failing case before trying to fix the issue. If you can help with that, I'm willing to try and fix it. I have the existing test suite running (although I get five failures). To that I've added a
I run the tests in a virtual environment as:
How can I test these? |
Wouldn't a possible fix be as follows: After performing the initial request which returns a response with alternate link headers:
|
Let's say I have this extremely minimal bit of JSON-LD to be expanded with pyld:
If I susbtitute "https://schema.org" with "https://schema.org/docs/jsonldcontext.jsonld", with the code otherwise unchanged, it will correctly print (as I expected):
However, that then seems to mess up other parsers, including the Google Structured Data Testing Tool.
The root issue seems to be with pyld's remote fetching of contexts, in that "https://schema.org/" does not now have an
application/ld+json
content-type, instead opting to useLink
header withrel=alternate
andtype=application/ld+json
. It seems that pyld needs to be updated to handle that case:If you do
curl https://schema.org/ -H "Accept: application/ld+json"
you will still get back an HTML response.Perhaps the cleanest way to implement this would be to check if a non-JSON-LD response is recieved, and if so, to look for an appropriate
Link
header and then make a request there.The text was updated successfully, but these errors were encountered: