Skip to content
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

Identify Feature in XML Mode forcing Accept header to application/xml when Resolving external #134

Open
sgrellet opened this issue Mar 12, 2021 · 3 comments
Assignees
Labels
bug Houston, we've a problem!
Milestone

Comments

@sgrellet
Copy link
Member

Environment

  • Plugin version: 1.3.1
  • QGIS version: 3.16.2-Hannover Hannover, f1660f9da5
  • Operating System: Windows 10
  • Python version: 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)]

Description

  • in a GML file, when appending content (Resolve external), the Accept header is forced to application/xml.
  • this may cause issue in content negociation as most of the time we resolve (note: for now the plugin is in "XML" paradigm)
    • to application/gml+xml for features
    • to application/rdf+xml for vocabularies

To Reproduce

Steps to reproduce the behavior:
Attached file: BoreholeView_Instance.zip

  1. Load the attached file in the Load Wizard > File/URL
  2. Loading options > 'Load in XML mode'
  3. Next and Finish
  4. epos:status > Resolve external > Embedded

-> Python error
"XML parsing error" : The external resource is not a well formed XML

Expected behavior


Additional context

  • QGIS 'Network Logger' (F12) shows an Accept header set to application/xml

  • querying that URI in a application such as PostMan with Accept header set to application/xml leads to fetching the wrong serialization from a linked data registry. it should be application/rdf+xml (in an XML paradigm)

  • but we cannot fix it to application/rdf+xml as it will have a side impact when we ask for application/gml+xml

  • idea

    • either ask the client in the GUI
    • or try various Accept values (like what normal web client do) : application/xml, application/rdf+xml
@sgrellet sgrellet added the bug Houston, we've a problem! label Mar 12, 2021
@Guts Guts added this to the 1.3.2 milestone Mar 12, 2021
@Guts
Copy link
Collaborator

Guts commented Nov 4, 2021

It seems that the server use an URL query parameter format to determine which output is expected. For example for rdf/xml: https://data.geoscience.earth/ncl/BoreholeStatus/drillingCompleted?_format=rdf

@sgrellet is there a way to get this kind of information (accepted content to use) from original XML?

cURL samples:

curl -H "Accept: application/rdf+xml" -X GET https://data.geoscience.earth/ncl/BoreholeStatus/drillingCompleted

works, but:

curl -H "Accept: application/xml,application/rdf+xml" -X GET https://data.geoscience.earth/ncl/BoreholeStatus/drillingCompleted

doesn't work. It returns HTML: text/html. It should returns one of the requested ones if it supports it.

BTW, the server doesn't answer with OPTIONS.

@Guts
Copy link
Collaborator

Guts commented Nov 4, 2021

The server doesn't answer with OPTIONS.

Guts added a commit that referenced this issue Nov 4, 2021
@sgrellet
Copy link
Member Author

@Guts : sorry for the latency.

no need to pass a 'format' parameter, just real conneg

in a 'XML' view of the world, "application/rdf+xml" should be your choice.
It makes sense the server does not know what yo do with application/xml as there is no obvious XML serialization for the linked data content available (note : I wrote XML" not "RDF/XML").

What do you mean by ' original XML' in your message above ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Houston, we've a problem!
Projects
None yet
Development

No branches or pull requests

2 participants