Network Service metadata: (random) error on the coupled resource metadata element (TG Req. 3.6) #515
Comments
|
Dear @AntoRot Thank you for opening this issue. We are currently investigating how requests to the coupled resources are being handled, as there is a redirection in the services that may be interfering with the caching system some times. We will get back to you as soon as we have more information. Kind regards, Carlos. |
|
Dear @carlospzurita Likewise, we would appreciate if you would answer the above described behaviour, as we have come to the same conclusion after internal checks. We were partially not able to reproduce the error 3.6 regarding the coupled resource. We also did an internal cross-check to rule out a potential unavailability of our infrastructure, but we did not reveal any failures during the monitoring process. Thanks in advance and kind regards. |
|
Dear @carlospzurita, |
|
Dear @carlospzurita , |
|
Dear @alitka, |
|
Dear @juanpelegrina,
Furthermore, we guess the above described behaviour is also a problem related to the INSPIRE Geoportal, because some records have neither a view nor a download option. Thanks in advance and kind regards. |
|
Dear @alitka, Thank you for the services that you provide us. We tested them and we were not able to reproduce the "is not an HTTP or HTTPS URL" error. We will keep investigating. Thank you and best regards. |
|
Dear @AntoRot, We are still investigating this problem. We ran the bunch of metadata that you provided us two times on the staging instance. On the first run, we received 5 "is not an HTTP or HTTPS URL" errors. But, on the second run, we did not receive any "is not an HTTP or HTTPS URL" error. We tried to check in the second run if there was a pattern in the metadata that failed, for example same origin on the coupled resource, but it seems that the error is not deterministic. Now we got two possible explanations for this situation: The second one, on the other hand, is that the validator has an error in his code. We have been looking into it and we found that on this line when a redirection is done, after some redirections the validator has misbehaviour and returns the error. The files that failed on the first execution are the following ones: We will keep investigating and we will keep you updated if any progress is done. Best regards. |
|
Dear @dperezBM, Thank you very much! I also made other attempts and got different behaviours by the validator. I tried to check more times the metadata records you provided in the zip folder in your comment through both remote file and file upload for the same record. The cases encountered are the following ones:
Best regards. |
ghost
mentioned this issue
|
We have been doing more tests with metadata from other countries (Spain) and we have not faced the "strange behaviour". We have run the tests several times and the result is always the same. It will be interesting if we could link the error with a specific type of service. Regards |
|
Thank you, @juanpelegrina! As soon as possible, I'll try to perform some other tests to check if the error is related only to specific types of services. Regards, |
|
Dear @juanpelegrina, I can't confirm, that the error is linked to a specific type of service. Attached, you find some resources with various
Also, I tested a bunch of resources with the current version of the INSPIRE validator, and the following records still have the 3.6-error, even though the provided link in the
Regards! |
|
Dear @alitka, Thank you for your feedback. We have also tested all seven metadata files that you provide us against the production and staging instance and we only received one error with this link. The error is because of a missing xlink:href attribute on the first operatesOn element. So we think the error is not related to the one we are experimenting with the metadata from Italy (‘An URL is not an HTTP or HTTPS URL’). Could you run the test again and let us know if you are still having the problem? Maybe we need to open a separate issue for this. We attached the reports that we get from the staging instance. Best regards. |
|
Dear @dperezBM You are right! During my first testing, I got the following error message: Best regards. |
|
Dear All, we have the same problem with service-metadata from two serviceproviders in Austria. The service-md UUIDS are:
Best regards |
|
Dear All, I can also confirm an other problem mentioned in this thread: XML document 'xml.xml', record '19d8c5af-8228-4b99-be0a-cfcbd382ff98': The metadata record has a linkage property, but it references a resource at 'http://data.inspire.gv.at/0046/c7fa03c8-66f0-49c8-ae5d-c0b22839a766' that cannot be accessed. An exception occured when accessing the resource. Error message: "https://data.inspire.gv.at/0046/c7fa03c8-66f0-49c8-ae5d-c0b22839a766" (Line 2): The markup in the document following the root element must be well-formed. This issues occur in the following service-md:
I saw, that problems with URL redirections are also mentioned in other threads. Best regards. |
I did a double check and at different times the achieved results are not equal/ constant, please see attached report AT_md-3.6_check.zip:
|
|
Thanks @alitka, and, again, the "bad" coupled ressource is the FIRST entry in the operatesOn block. Best regards |
|
Dear @alitka, Since you commented on your results, we have tested the metadata included on the report on several occasions (production, staging and localhost instances) and we always get “passed” results. We will carry on to see if we also get an unstable result Thank you and best regards. |
|
Dear @dperezBM, I attached 2 zips with validator logs;
As @alitka said: the results seem to be very unstable; operatesOn-URLs were accessible online at both times We found these problems in all service-mds whose UUIDs are mentiones in my comments above Best regards |
|
Dear @dperezBM , I did an automatic long-term test on our local ETF-instance with a bunch of metadata records (5) and I received unstable results. Please see attached reports AT_md-3.6_reports.zip. Best regards. |
|
Dear @alitka, Thank you for your reports. To continue analyzing this behaviour on the validator, could you please share with us the full reports and the metadata you tested with us? This will be so helpful for us. Thank you and best regards. |
|
Dear @dperezBM , I did the test with these 5 service records: AT_md-services.zip. I already send you the full reports within my last comment. Best regards, |
|
Dear @alitka, Thank you for your response. We will keep investigating the services that you provide us. Sorry for my misexplanation about the reports. I was referring to the reports that the INSPIRE validator generates. You can download those on the 'Test Report' section, selecting your report and clicking on the 'Download Report' button. This will provide us with a log record of the execution of the test run. Thank you and best regards. |
|
Dear @dperezBM , As I already wrote, I did an automatic long-term test on our local ETF-instance. Therefore, I'm not able to provide you the Best regards. |
|
Dear users, We have updated our staging instance adding new log messages to analyze this issue in more detail. These messages will help us to collect the URL and the response it brings as text on the report log. Unfortunately, this implementation is not available in production, so we request if possible, that when you detect this failure in staging, you attach the downloaded report to analyze these new messages. Thank you very much and best regards. |
|
Dear @dperezBM
"Unfortunately" all md passed the validator, but I will try it within the next days again and inform you about bad results. The problem seemed to be the stability of the results. Best regards |
|
Dear @dperezBM
10 minutes later:
??????????????????????? |
|
Dear users, We have been checking this issue and we are looking for possible explanations on this. One thing that stands out for the links in the We are also establishing the differences between the staging and production instance that may be causing the error to appear. Will keep you posted on any findings that we may reach. Kind regards. |
|
Dear @carlospzurita, We also did some internal checks in Germany again. During this testing and analysing phase, we got the following message from one of our providers: DST Root CA X3 Expiration
Either way, it is out of our control, and we would recommend updating the certificates of the INSPIRE-Validator. Thanks and kind regards. |
When analysing the monitoring results at the end of January, I noticed that for some metadata records coming from the Italian national discovery service an error was raised on the coupled resources metadata element (i.e.
srv:operatesOn) as the linkage property included "is not an HTTP or HTTPS URL". But it was/is and it worked/works!I performed again the same test on the same metadata records one week ago and this time no errors were raised, although those metadata records haven’t been changed.
I performed the test one more time this morning in order to open this issue and this time the error mentioned above was raised again.
The metadata record tested is: https://geodati.gov.it/RNDT/rest/document?id=c_l219:00ceb6c6-54f4-4e00-a8fb-674fe827b3ae
The Test Report: https://inspire.ec.europa.eu/validator/v2/TestRuns/EIDdd4c6a96-0d03-41eb-889f-b52c66ae1a8d.html
The Assertion URI: https://inspire.ec.europa.eu/validator/v2/TestRuns/EIDdd4c6a96-0d03-41eb-889f-b52c66ae1a8d.html#EIDa975b828-de90-47cc-9177-89dde928abef
Other examples of metadata records incorrectly affected by the same error are:
https://geodati.gov.it/RNDT/rest/document?id=p_bi:a521262a-ae08-4bfe-a7ea-f1f5284d2b29
https://geodati.gov.it/RNDT/rest/document?id=r_piemon:0787c578-38f1-4952-bdc4-af2873999770
As the resources tested are all network services, to be investigated if this error also occurs in case of invocable/interoperable/harmonised spatial dataset services.
Thank you,
Antonio
The text was updated successfully, but these errors were encountered: