-
Notifications
You must be signed in to change notification settings - Fork 71
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
HTTP Error 500: Internal Server Error => JSONDecodeError #84
Comments
it seems this issue started at 20:17.49 EDT May 18th and has broken all of our applications using the json-ld plugin. Is it possible that our repeated use of this plugin has caused us to be banned somewhere? |
as of 13:21.39 EDT May 19th, it appears to be back online, whatever it was, the very same code as above now produces a graph as expected. So clearly whatever this is, perhaps I need to prevent this fetch by providing my own local copy? |
and my day just keeps getting worse ...
it could be blindness from fatigue, but I'm nearly certain those two lines would have worked before. |
I have exactly the same issue. Worked fine yesterday, and today got the same errors as you. |
it has to be that mystery file that the plugin secretly fetches, some sort of definition spec for json-ld that was lost in their Monday crash and is now corrupted? I am using but none of this information has changed since last week -- strace does not appear to show any fetch of a remote file (that I can see) but the HTTP 500 errors overnight Monday do seem to indicate otherwise? here is my test script, I inserted json.loads to verify that the string is indeed json-compatible, but also to show that it isn't failing because of the rdflib-jsonld use of the json module; I also changed the context to a nonsense but valid url just in case example.com was triggering someting
This presently outputs the dict as expected, but followed by a failure in the json decoder.py
position 9718?? |
This is an error on the schema.org site. See: https://tinyurl.com/kk7k5qt (A link to the JSON-LD playground) that uses schema.org as well. Has anyone reported this issue to them??? |
@hsolbrig I'm curious, how do you know it is an error on the schema.org site? I don't know the internals of this thing very well (but apparently now is the time to learn) -- I couldn't find an easy means to contact json-ld.org, but I am in their IRC channel right now; there are 21 participants, but I fear these days IRC isn't first on anyone's list as a place to check |
dlongley at json-ld provides the following:
is returning nonsense |
They are aware: schemaorg/schemaorg#2578 |
Note: Libraries/applications should be either caching or installing a version of the schema.org JSON-LD context and loading it locally. A language/ecosystem appropriate package manager could then be used to manage updates to the context. This would mitigate this problem and improve performance for users. |
In a way I am thankful for their downtime overnight Monday because I was unaware that my code was hitting some service for every single json-ld parse job, and in some runs, I can be doing thousands in a very short time. So yes, a Conditional-GET might be in order, done during init, or done once on the first invocation and cached for the lifespan of the process, and if it fails, fall back to a local filesystem cached copy -- after years of using schema.org and rdflib-jsonld, I guess I had never tried to run one on a disconnected machine. schemaorg/schemaorg posted a merge into master that roughly correlates with when the HTTP 500 errors stopped and the parsing errors began update at 16:20 EDT: that curl test now returns HTML again (for a while it was returning binary) |
as we move into day 3 of this outage, and this is probably a naive question but @dlongley is there any alternate source to obtain that context so we can work towards getting our applications back online? |
If you run this:
You should get the latest schema.org context. |
thanks again -- I see today on the schema.org mailing list that this change in the accept header was intentional, a consequence of blocking a DoS attack, which was likely those HTTP 500 errors I saw Monday night. Dan Brickley writes:
|
Work-around: I have an ugly fix for those who need this working quickly, I won't submit a PR because this isn't a fix, it's a hack that (in my case) works:
save that as jsonfix.patch then (in linux) I do Improvements are very much appreciated |
A more general solution may be to support Link headers [1, 2] for resolving the location of external contexts (when not available in a local cache). See also #85. When parsing JSON-LD, redirect handling actually happens in rdflib in The parser uses I made a PR for supporting link headers (patch available at https://patch-diff.githubusercontent.com/raw/RDFLib/rdflib/pull/1125.patch ) for the specific case of JSON-LD parsing, though this would generally change the behavior of URLInputSource when a Link header is present for the This change resolved schema.org context parsing for me, and also works with other context documents referenced through link headers. [1] https://tools.ietf.org/html/rfc8288 |
"it worked yesterday!"
I have a simple json-ld string to load into a Graph and it never occurred to me that this should require urllib, but apparently it does, and I'm guessing the target site is down:
only looking at line 186 (naively) in parser.py, it looks like it is taking the
data
value as a URL?or am I missing something else? I found reference to the HTTP 500 in the context of linkeddata/rdflib.js#364 which points to a fetch from solid, but I don't know enough about rdflib internals to say for sure.
The text was updated successfully, but these errors were encountered: