Unable to disable Strict Content Type Validation

I am trying to use a yum proxy to Centos 8 EPEL, but I keep getting 404’s on xml.xz files. The only entry in the Nexus log is that is about “An exception occurred determining the content type of asset”. I have tried to disable Strict Content Type Validation but it does not help fix the issue.

Is this a bug, or am I doing something wrong?

Nexus version:
Nexus OSS 3.21.1-01

Client error:

Cannot download ‘https://reposerver/repository/epel_mirror_2/8/Everything/x86_64/’: Yum repo downloading error: Downloading error(s): repodata/af449e2ed3e8482345740f973eab1fd3054df95d9eb701800529c05c6c9a1e31-prestodelta.xml.xz - Cannot download, all mirrors were already tried without success.

(showing 404 when trying from a browser)

Server log:

2020-03-27 11:05:00,594+0100 DEBUG [qtp350052038-1047] *UNKNOWN org.sonatype.nexus.httpclient.outbound - https://mirror.netsite.dk/epel/8/Everything/x86_64/repodata/af449e2ed3e8482345740f973eab1fd3054df95d9eb701800529c05c6c9a1e31-prestodelta.xml.xz < HTTP/1.1 200 OK @ 20.83 ms
2020-03-27 11:05:00,597+0100 WARN [qtp350052038-1047] *UNKNOWN org.sonatype.nexus.repository.storage.StorageTxImpl - An exception occurred determining the content type of asset 8/Everything/x86_64/repodata/af449e2ed3e8482345740f973eab1fd3054df95d9eb701800529c05c6c9a1e31-prestodelta.xml.xz in repository epel_mirror_2

Proxy configuration:

{
“name”: “epel_mirror_2”,
“format”: “yum”,
“url”: “REMOVED”,
“online”: true,
“storage”: {
“blobStoreName”: “EPEL”,
“strictContentTypeValidation”: false
},
“cleanup”: null,
“proxy”: {
“remoteUrl”: “REMOVED”,
“contentMaxAge”: 1440,
“metadataMaxAge”: 5
},
“negativeCache”: {
“enabled”: false,
“timeToLive”: 5
},
“httpClient”: {
“blocked”: false,
“autoBlock”: true,
“connection”: {
“retries”: null,
“userAgentSuffix”: null,
“timeout”: null,
“enableCircularRedirects”: false,
“enableCookies”: false
},
“authentication”: null
},
“routingRuleName”: null,
“type”: “proxy”
},

Sounds like a bug to me.
It looks like there should be a second WARN after the one you provided about content validation (added with https://issues.sonatype.org/browse/NEXUS-17502) however that also means that content validation should help.
If it doesn’t or there’s no second WARN, I’m guessing bug.
Unless others have feedback, if you could file in issues.sonatype.com that’d get it on our radar.
Appreciate the report,
Joe

Thanks for the response Joe, and sorry for omitting the second warning. Here are all the log entries when getting a 404:

2020-03-30 17:20:30,437+0200 DEBUG [qtp350052038-5268] admin org.sonatype.nexus.httpclient.outbound - https://mirror.netsite.dk/epel/8/Everything/x86_64/repodata/563bda0102ebf52883e3e8bcd7ca7e1f61e4b1438e19a9f38da53587762b2881-prestodelta.xml.xz > GET /epel/8/Everything/x86_64/repodata/563bda0102ebf52883e3e8bcd7ca7e1f61e4b1438e19a9f38da53587762b2881-prestodelta.xml.xz HTTP/1.1
2020-03-30 17:20:30,577+0200 DEBUG [qtp350052038-5268] admin org.sonatype.nexus.httpclient.outbound - https://mirror.netsite.dk/epel/8/Everything/x86_64/repodata/563bda0102ebf52883e3e8bcd7ca7e1f61e4b1438e19a9f38da53587762b2881-prestodelta.xml.xz < HTTP/1.1 200 OK @ 139.6 ms
2020-03-30 17:20:30,579+0200 WARN [qtp350052038-5268] admin org.sonatype.nexus.repository.storage.StorageTxImpl - An exception occurred determining the content type of asset 8/Everything/x86_64/repodata/563bda0102ebf52883e3e8bcd7ca7e1f61e4b1438e19a9f38da53587762b2881-prestodelta.xml.xz in repository epel_mirror_2
2020-03-30 17:20:30,580+0200 WARN [qtp350052038-5268] admin org.sonatype.nexus.repository.view.handlers.ExceptionHandler - Invalid content: GET /8/Everything/x86_64/repodata/563bda0102ebf52883e3e8bcd7ca7e1f61e4b1438e19a9f38da53587762b2881-prestodelta.xml.xz: org.sonatype.nexus.repository.InvalidContentException: Content type could not be determined: off

I have just been testing with curl -I against two external repositories, and I can see that it works against one server, and not the other. On the working one, the content-type seems correct, and the other just gives “off”. Here is the detected content-types from curl:

Working repo:

Content-Type: application/x-xz

Error repo:

content-type: off

That even more seems like a bug, or at least something I’ve never seen.
I am assuming the content type validation isn’t “off” :slight_smile:
-Joe