Dev - Nexus
  1. Dev - Nexus
  2. NEXUS-3709

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

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.7.1
    • Fix Version/s: 1.8.0
    • Component/s: Repository
    • Labels:
      None
    • Global Rank:
      5737

      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.

        Issue Links

          Activity

          Hide
          Brian Demers added a comment -

          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)

          Show
          Brian Demers added a comment - 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)
          Hide
          Peter Lynch added a comment -

          jars, ears, wars, zip, poms, and xml files should all be checked to have valid content now

          Show
          Peter Lynch added a comment - jars, ears, wars, zip, poms, and xml files should all be checked to have valid content now
          Hide
          Peter Lynch added a comment -

          Manually verified this is fixed in nexus-oss-1.8.0-20100907.133559-11 using the following technique.

          1. 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.

          2. 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
          3. 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.

          Show
          Peter Lynch added a comment - 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.

            People

            • Assignee:
              Peter Lynch
              Reporter:
              Rich Seddon
              Last Updated By:
              Rich Seddon
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Date of First Response: