Content-Type confusion for zipped gml files in ATOM dataset feed #1121
Comments
|
Dear @dhdeangelis, I don't know if you introduced further changes since the service is valid now: https://inspire.ec.europa.eu/validator/test-run/details.html?id=EID3fc03268-aab3-4b97-8b8e-bc854f2a8841 |
|
Dear @fabiovinci thank you for testing. I see that opensearch validates OK on the production instance, yet it gives an error on "media-types" despite using a media type listed in the Inspire Registry. We will try other options, including going back to application/zip |
|
@fabiovinci I have now tested quite extensively and find it strange that I am getting this sort of error even with services that were testing OK jsut a few weeks ago: https://inspire.ec.europa.eu/media-types/media-types.es.atom
I am starting to suspect that there may be a bug somewhere, not necessarily in the validator itself but perhaps in the chain of connections to/from the Inspire Registry. Could that be the case? |
|
I see it may be related to this: #1123 |
|
Dear @dhdeangelis, I confirm there is a problem with the registry. |
|
Dear @dhdeangelis, the Registry issue has been solved. |
|
Dear @fabiovinci thank you for solving the issue with the Registry. The original issue with content-type still occurs when running validator 2024.3 on a Docker in a Linux machine. However it does not occur when using the staging instance (production instance seems to be unavailable at the moment). When testing the service from the staging instance we get it passed (green). When running 2024.3 from a local Docker instance (Linux) we get the following error message in "Iterate over Get Spatial Dataset URL": All our dataset links in dataset feeds look like this example: How is it possible that "application/zip" is accepted by the staging instance but not by the local docker instance? |
|
Dear @fabiovinci I wonder if there has been any chance to look at this. I have now tested extensively and I am still baffled by the following error: On one hand, this service: does not pass validation on the following error: the downloadable element in all its dataset feeds are formatted like this: On the other hand, this other service: passes validation OK. The downloadable element in all the dataset feeds look like this: As you see, both services are written in the same exact way, using "application/zip" for all zipped gml files. Yet one produces an error on contentType and the other not. What could be happening here? Tested on 2024.3 on a local docker instance in Linux. |
|
Dear @dhdeangelis, I tested both of your services with the production instance, and both services passed the validation:
We have encountered challenges in the past when determining the Content-Type, as the results vary over time. The link containing the .gml string is responding with the
The link not containing the .gml string is responding with the Currently, the only suggestion is to remove the .gml string from the links. In the meantime, we will continue to investigate the Content-Type response. |
|
Thank you @fabiovinci , that was good catch ! |
|
@fabiovinci we have now changed all our files to |
|
Short update on this: we found that one of our servers (Windows IIS) assigns a content type string "application/x-zip-compressed" to ZIP files. This has now been changed. Our service will be retested as soon as the changes enter production. This may be of interest for anyone using this kind of server. |
|
Dear @dhdeangelis, that's a great discovery! |
Using validator versions 2024.2 and 2024.3 in a local Docker instance.
Testing the following ATOM service:
https://stationsregister.miljodatasamverkan.se/docs/atom/atomTopFeed.xml
We get the following problem:
Expected 'application/zip' as Content-Type header but server returned 'application/x-zip-compressed'This is new. We have served zip compressed gml from this ATOM service for a long time without validation issues. We serve packages called
*.gml.zipwith dataset feeds that have the declarationtype="application/zip. This has worked well before.Testing these files locally retrieves application/zip:
We have tested replacing
type="application/zipwithtype="application/x-gmzbecause as stated in the TG only types described in the registry should be used, but this has not worked either.Other ATOM services built in the same way but serving packages called
file.zip( instead offile.gml.zip) pass validation with no issues. See for example:https://geodata.havochvatten.se/download/fiskets-geografier/atom-topfeed.xml
It is not obvious that this is a problem with the validator, but it is very confusing anyway.
Could this be an issue with how browsers or operative systems read and manage MIME types?
As an example, a test using https://mimetype.io/ with the served files retrieves
application/zipas content type, but recommends usingapplication/zip-compressedinstead.What should be the right way to proceed here?
The text was updated successfully, but these errors were encountered: