Network Service metadata: (random) error on the coupled resource metadata element (TG Req. 3.6)

[AntoRot]

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

[carlospzurita]

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.

[alitka]

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.

[alitka]

Dear @carlospzurita, Any news to your investigation, how requests to the coupled resources are being handled? Thanks in advance and kind regards.

[alitka]

Dear @carlospzurita , The above described behaviour regarding the coupled resource' metadata element are still an urgent issue for us. Therefore, we would like to ask if you have made already any progress discussing this internally? Thanks in advance and kind regards.

[juanpelegrina]

Dear @alitka, We are still investigating this problem, we have done several tests to find the cause of the problem. Have you experienced a similar error? In case you have, could you point us to the Network service metadata you are testing? Regards

[alitka]

Dear @juanpelegrina, During our two-month monitoring period, we could reproduce this error only once, e.g., with the following records:

• https://gdk.gdi-de.org/gdi-de/srv/api/records/11830E3C-BBE7-4FA4-B1FE-7C7BB25EB31C/formatters/xml
• https://gdk.gdi-de.org/gdi-de/srv/api/records/2B5245BD-6BEA-4925-8F8B-E28FDA579A00/formatters/xml
• https://gdk.gdi-de.org/gdi-de/srv/api/records/cffc6076-3b12-4bb7-b058-6c9ade94e8ea/formatters/xml

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.

[dperezBM]

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.

[dperezBM]

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 first one is that the service fails under a specific situation, which makes the error harder to reproduce for us.

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: 20241-20260\17.iso19139 20321-20340\11.iso19139 20361-20380\13.iso19139 20361-20380\15.iso19139 20381-20400\5.iso19139

noHTTP.zip

We will keep investigating and we will keep you updated if any progress is done.

Best regards.

[AntoRot]

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:

• when checking the first file in the zip folder (i.e. 20381-20400\5.iso19139) I got the error in 2 out of 4 attempts (the first 2 ones by using first the remote file and then the file upload);
• I didn't get any error when checking the 3 files 20321-20340\11.iso19139, 20361-20380\13.iso19139, 20361-20380\15.iso19139;
• I got the error when checking the file 20241-20260\17.iso19139 through file upload, but I didn't get the error using the remote file.

Best regards.

[juanpelegrina]

Dear @AntoRot and @alitka

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 Juan

[AntoRot]

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, Antonio

[alitka]

Dear @juanpelegrina,

I can't confirm, that the error is linked to a specific type of service. Attached, you find some resources with various operatesOn entries, which have had the 3.6-error during the last monitoring process.

• https://gdk.gdi-de.org/gdi-de/srv/api/records/342649d0-73ce-3f68-a386-420ae4182657/formatters/xml = <srv:operatesOn xlink:href="https://registry.gdi-de.org/id/de.be.csw/397e6253-4bf5-35eb-b4f8-efbd9ad01c2b" /> = possible cause of error: response time of the catalogue
• https://gdk.gdi-de.org/gdi-de/srv/api/records/b9ba8698-b88d-4fb3-83cb-8733746ab209/formatters/xml = <srv:operatesOn uuidref="51611cec-07d7-4a68-94a4-900ca766a901" /><srv:operatesOn xlink:href="http://www.geodaten-mv.de/geomis/id/51611cec-07d7-4a68-94a4-900ca766a901" /> = possible cause of error: two "different" operatesOn-entries
• https://gdk.gdi-de.org/gdi-de/srv/api/records/05E79D38-4FEE-47E7-B14A-74D589A4F1C1/formatters/xml = <srv:operatesOn uuidref="209FF13F-A3BD-4B23-9C1C-CCDD8DA7D9BF" xlink:href="https://registry.gdi-de.org/id/de.hb/799305d0-3a95-4bf7-be15-a7bcbcfccb58" /><srv:operatesOn uuidref="080C5956-E778-4AEB-A725-25A90D256440" xlink:href="https://registry.gdi-de.org/id/de.hb/FHB-080C5956-E778-4AEB-A725-25A90D256440" /><srv:operatesOn uuidref="670A62AE-AD9F-455E-BFDE-119540825EF7" xlink:href="https://registry.gdi-de.org/id/de.hb/67e71074-1076-443e-af6f-cc5fd602b07b" /><srv:operatesOn uuidref="AB918C04-C01C-4CBA-A7AA-E7505AA8D20E" xlink:href="https://registry.gdi-de.org/id/de.hb/8036be8a-7a6e-4635-816b-ef85704b7507" /><srv:operatesOn uuidref="D60C5C07-6D7F-427D-B9D9-A91555CD50BF" xlink:href="https://registry.gdi-de.org/id/de.hb/8c22e684-3305-4462-a75f-6146268b0c76" /> = possible cause of error: more than one operatesOn entry

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 operatesOn-element is available:

• https://gdk.gdi-de.org/gdi-de/srv/api/records/17720ea9-2a00-4866-8eef-6df1db2afa5c/formatters/xml
• https://gdk.gdi-de.org/gdi-de/srv/api/records/0c6aeb8b-3113-3932-83a1-452be1eef2db/formatters/xml
• https://gdk.gdi-de.org/gdi-de/srv/api/records/B71EA76D-6241-41C9-BC38-57D3B62AE222/formatters/xml
• https://gdk.gdi-de.org/gdi-de/srv/api/records/2d3f0cb2-b322-427a-bb62-dab329fcb870/formatters/xml

Regards!

[dperezBM]

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.

issue-515-reports.zip

Best regards.

[alitka]

Dear @dperezBM

You are right! During my first testing, I got the following error message: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: timestamp check failed, except for the record 'b9ba8698-b88d-4fb3-83cb-8733746ab209'. The second time, I just only got this error for the record '05E79D38-4FEE-47E7-B14A-74D589A4F1C1' (the other six records passed the test).

Best regards.

[oberseri]

Dear All,

we have the same problem with service-metadata from two serviceproviders in Austria. There are many coupled ressources per service and in all oft the service-md ONLY THE FIRST coupled ressource is marked in the error report as (no difference to the other entrys): XML document 'xml.xml', record '7c815c5d-f641-47ff-8e1e-68b6aea686c0': The metadata record has a linkage property, but it references a resource at 'https://www.geoland.at/geonetwork/srv/en/csw?service=CSW&request=GetRecordById&version=2.0.2&outputSchema=http://www.isotc211.org/2005/gmd&elementSetName=full&id=ba27e261-f505-49b7-94ed-6b2845744bcf' that is not an HTTP or HTTPS URL.

The service-md UUIDS are:

• 7c815c5d-f641-47ff-8e1e-68b6aea686c0
• a0f3a4e1-52ed-46c9-b64c-eae6d2ab9783
• 6db957ed-d923-4192-a3f8-50aa00da12ac
• 2242c584-081e-437a-8492-00254aa17702
• fbdd9c8a-7cef-4c44-938f-2d556fff52ba

Best regards

[oberseri]

Dear All,

I can also confirm an other problem mentioned in this thread: Linking coupled ressources to a Redirected URL gives the following error message:

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:

• 19d8c5af-8228-4b99-be0a-cfcbd382ff98
• c0901f78-9c34-4a01-b6ed-21bd02017b2d
• 9f700f35-c02f-42d3-99b8-28f23ee9bba5
• e993a684-ab3a-4427-8e6b-ed0eea48e1f1

I saw, that problems with URL redirections are also mentioned in other threads.

Best regards.

[alitka]

• [x] used browser and version: Firefox Browser 91.2.0esr (64-Bit)
• [x] check service-md: 2242c584-081e-437a-8492-00254aa17702

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:

1. result: AT_md-3.6_passed
2. result: AT_md-3.6_failed

[oberseri]

Thanks @alitka,

and, again, the "bad" coupled ressource is the FIRST entry in the operatesOn block.

Best regards Erik

[dperezBM]

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 @oberseri, could you please share with us the data you have been testing in order to have a bunch of data to make tests?

Thank you and best regards.

[oberseri]

Dear @dperezBM,

I attached 2 zips with validator logs;

• one with 4 "not a HTTPS URL" errors (today one of them passed the validator; I tested only only of them today)
• one with a "must be well formed" error (today it passed the validator) [operatesOn links to a redirected URL]

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

notHTTPS_problems.zip redirectedURL_problem.zip

[alitka]

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.

[dperezBM]

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.

[alitka]

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,

[dperezBM]

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.

[alitka]

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 log record of the execution of the test run.

Best regards.

[dperezBM]

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.

[oberseri]

Dear @dperezBM I just tested

• 7c815c5d-f641-47ff-8e1e-68b6aea686c0
• fbdd9c8a-7cef-4c44-938f-2d556fff52ba from the first block and
• 19d8c5af-8228-4b99-be0a-cfcbd382ff98
• e993a684-ab3a-4427-8e6b-ed0eea48e1f1 from the second block above (staging logs attached). Downloads.zip

"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

[oberseri]

Dear @dperezBM I just tested 7c815c5d-f641-47ff-8e1e-68b6aea686c0 with original and staging validator:

• staging: OK
• original: error Desktop.zip

10 minutes later:

• both validations OK Downloads.zip

??????????????????????? Best regards

[carlospzurita]

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 operatesOn tag which throw errors, is that there is a redirection on the CSW to change the language path from en to eng. This happens across all metadata records that we have checked that present this error, and there may be a relation in how the production instance handles the redirections and the errors.

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.

[alitka]

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

MetaVer is using the new certificate for some time now and clients connecting to MetaVer need to make sure to detect the new root certificate. Another possibility could be an outdated library used in the INSPIRE Validator, which does not accept the new certificate.

Either way, it is out of our control, and we would recommend updating the certificates of the INSPIRE-Validator. Maybe this solves the problems related to the German metadata records.

Thanks and kind regards.