Need a way to deal with proxy servers that return 200 with error pages.

Details

Description

It is fairly common for larger sites to have proxy servers which redirect to an error page when something goes wrong in an HTTP request. This can cause invalid artifacts to be stored in proxy repositories, since the redirect URL usually returns 200 or similar.

Depending on the server it may not be possible to change this behavior, and the obvious workaround of enabling strict checksums isn't always feasible because not all remote repositories have valid checksums for all artifacts.

We should provide a workaround for users who find themselves in this situation.

One possibility would be to check for some information in the http headers to indicate to nexus that the artifact should not be cached.

Another thought: A"valid checksum" mode, where nexus requests the checksum file but only checks to see that it has a valid format. If a checksum is received with non-error response and it isn't in valid format the artifact would be rejected.

Brian Demers
added a comment - 09/07/10 05:20 PM Added a new field in the UI for proxy repos ( File content validation ) it is disabled by default, and can be enabled on any proxy repo. (it should show up under the checksum policy option)

Using variations of the above setup, built maven-3 trunk ( a project that can get all artifacts from maven central )
against the nexus3709 repo. Verified no content that was matched by AliasMatch directive was written to local repo or within the storage of nexus3709 on the nexus server. Maven treated the artifact as not being able to retrieve(404) if the content of a jar or pom was simple text, even though strict checksum checking for nexus3709 was off. Also manually check zip files as well.

Attached is a screenshot of the new content validation option in the repository configuration screen.

Peter Lynch
added a comment - 09/07/10 08:50 PM Manually verified this is fixed in nexus-oss-1.8.0-20100907.133559-11 using the following technique.
httpd was running at localhost with the following config:
AliasMatch /nexus3709/org/.* /Users/plynch/index.html
ProxyPass /nexus3709/org/ !
ProxyPass /nexus3709 http: //127.0.0.1:8081/nexus/content/repositories/central
ProxyPassReverse /nexus3709 http: //127.0.0.1:8081/nexus/content/repositories/central
/Users/plynch/index.html contained a simple test string only, to mimic what may be returned from a proxy server.
Started Nexus bundle and added a new proxy repo proxying content from http://localhost/nexus3709
Exposed the above repo at http://127.0.0.1:8081/nexus/content/repositories/nexus3709
Adjusted .m2/settings.xml to specify mirror for http://127.0.0.1:8081/nexus/content/repositories/nexus3709
Using variations of the above setup, built maven-3 trunk ( a project that can get all artifacts from maven central )
against the nexus3709 repo. Verified no content that was matched by AliasMatch directive was written to local repo or within the storage of nexus3709 on the nexus server. Maven treated the artifact as not being able to retrieve(404) if the content of a jar or pom was simple text, even though strict checksum checking for nexus3709 was off. Also manually check zip files as well.
Attached is a screenshot of the new content validation option in the repository configuration screen.