401 unauthorized when using apoc.load.xml

[pdrangeid]

• neo4j version 3.5.3 community edition
• apoc-3.5.0.2-all (I also tested against the new spring release (3.5.0.3 - same behavior)
• site uses basic http auth, so no headers or params are required, auth is just in the url
  other API calls (although using apoc.load.json) work fine from this same neo4j server.

If I use a regular browser the xml file is automatically downloaded as expected. (tested on the neo4j server itself, to verify the call could be made from the same computer as the neo4j server)

, but via an apoc.load.xml call I receive:
Failed to invoke procedure apoc.load.xml: Caused by: java.io.IOException: Server returned HTTP response code: 401 for URL:

cypher code is as follows:

WITH "https://myapitoken:x@console.mailprotector.com/domains.xml" AS url
CALL apoc.load.xml(url) YIELD value
return value

[pdrangeid]

Found the issue. apoc.load.json will perform the conversion of the url string http://user:password@mysite.com and must do the Authorization: Basic (base64) conversion on your behalf automatically?

the apoc.load.xml does not do this. You must perform the base64 conversion yourself (unless there is a function to do this using apoc or cypher natively?

this code worked:

WITH {`Authorization`:' Basic sdhjfoisdfjl43kjt5k='} as xmlheaders
WITH xmlheaders,"https://yoursite.com/yourpage.xml" AS url
CALL apoc.load.xml(url, '', { headers: xmlheaders }) YIELD value
return value

[stefan_armbrust]

Please create a gh issue at https://github.com/neo4j-contrib/neo4j-apoc-procedures/issues. Good to know you've found a workaround.

[pdrangeid]

pdrangeid:

• community edition
• apoc-3.5.0.2-all (I also tested against the new spring release (3.5.0.3 - same behavior)
• site uses basic http auth, so no headers or params are required, auth is just in the url
  other API calls (although using apoc.load.json) work fine from this same neo4j server.

If I use a regular browser the xml file is automatically downloaded as expected. (tested on the neo4j server itself, to verify the c

Stefan, I'm not very confident that my statement above is accurate, because I've never used the apoc.load.xml before. After exchanging emails with their support, it is clear that they expect the "authorization" xml header, and do NOT support parsing it in the URL, although it DOES work via the chrome browser (perhaps does the chrome browser automatically and transparently detect user:password@domain.com/url and convert the user:password to an authorize HTML header on my behalf?) , it could very well be that my other API providers are properly parsing the user/password from the URL string, and that this provider is not, so I'm not very confident that I'm reporting a true issue with apoc.load.xml (thankfully only one of my providers is forcing me to use XML, the rest have a more modern REST Json based API!)