Uploaded image for project: 'Dev - Nexus Repo'
  1. Dev - Nexus Repo
  2. NEXUS-10644

support webapp context path and repository path transparent forwarding

    XMLWordPrintable

    Details

    • Type: Story
    • Status: Done
    • Priority: Major
    • Resolution: Parked
    • Affects Version/s: 2.13, 3.0.1
    • Fix Version/s: None
    • Component/s: Transport
    • Labels:
      None

      Description

      Nexus 2 and Nexus 3 support basic reverse proxying scenarios by way of X-Forwarded-* headers.

      The supported configuration enabled out of the box is:

      1. Host header - host name and port are read from here by default - Host header is required by HTTP spec.
      2. AbstractConnector(Nexus2) jetty config set hostHeader value - this is used in place of inbound host header, no x-forwarded headers are consulted if set
      3. X-Forwarded-Host header- This overrides Host header values for host name and port, if config is not set
      4. X-Forwarded-Server header - This overrides *server name* value , if hostHeader config and x-forwarded-host is not set in a request
      5. X-Forwarded-Proto header - if set, this overrides what url protocol is being used during the request. ( http or https )

      In summary, all that could be changed by the above is host name, port and protocol.

      Similarly related is the server Base URL value in Nexus: This URL is only used to produce base URLS to the Nexus instance, outside the context of an active incoming HTTP request ( think scheduled task emails ), where incoming HTTP headers cannot be consulted.

      When reverse proxying Nexus, our current requirement is that the webapp and context path parts of the request must remain intact and unmodified and must be passed through as received by reverse proxy. The reason is that some metadata returned by some repository formats include absolute and relative links to other locations in the server. Since the server code cannot know if a reverse proxy is remapping the URL path parts, then its only option is to believe it is being accessed on the repository path that Nexus exposes directly.

      Customers want to reverse proxy Nexus instances at URLs that may include differences in the other two parts of request - these are:

      • webapp context path
      • defacto content path

      Example Desired Use Cases:

      URL Part Reverse Proxy NX2 Repository Manager
      URL https://mvn.example.com/ http://nexus.local:8081/nexus/content/repositories/central
      proto https http
      host mvn.example.com nexus.local
      port 80 8081
      webapp context path / /nexus
      repo content path / content/repositories/central
      URL Part Reverse Proxy NX2 Repository Manager
      URL https://npm.team.example.com/ http://nexus.local:8081/nexus/content/groups/npm
      proto https http
      host npm.team.example.com nexus.local
      port 443 8081
      webapp context path / /nexus
      repo content path [empty string] content/groups/npm
      URL Part Reverse Proxy NX3 Repository Manager
      URL https://npm.team.example.com/nexus http://nexus.local:8081/repository/npm-group
      proto https http
      host npm.team.example.com nexus.local
      port 443 8081
      webapp context path /nexus /
      repo content path [empty string] repository/npm-group

        Attachments

          Activity

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            plynch Peter Lynch
            Last Updated By:
            Joe Tom Joe Tom
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:
              Date of First Response:

                tigCommentSecurity.panel-title