Skip to main content

Inspecting Inbound Request Headers in Nexus Repository 3

Peter
Updated

You can inspect the HTTP request headers being sent into Nexus Repository 3.

This is especially helpful to prove that your reverse proxy is sending Nexus Repository 3 the correct header values.

Nexus Repository 3 request logging utilizes Logback Access and therefore the log lines printed inside the request.log can be customized by adjusting the PatternLayout.

Editing the Request Log Pattern

Find this file in a text editor:

  • Nexus Repository 3: <app-dir>/etc/logback/logback-access.xml

Find the line that defines the request.log pattern - it should look similar to this:

  <pattern>%clientHost %l %user [%date] "%requestURL" %statusCode %bytesSent %elapsedTime "%header{User-Agent}"</pattern>

The pattern can be changed to print additional inbound request headers. Once you change the pattern, restart Nexus Repository for it to pick up the changes.

Access Nexus Repository through your reverse proxy server while monitoring request.log

If a header is being sent to Nexus Repository 3, its value should display in the logs.

If a header is not being sent to Nexus Repository 3 a single dash ( - ) will display instead.

HTTP header names and therefore the header pattern names are case insensitive.

Example: Inspecting RUT Auth Headers

RUT Auth involves having a server sending a header to Nexus Repository 3 which contains a userid. The header name is configured inside Nexus Repository 3 in a RUT Auth capability.

Change the logback-access.xml pattern value so that the header with the userid is printed in the logs - here we use the example header name REMOTE_USER.

  <pattern>%clientHost %l %user [%date] "%requestURL" %statusCode %bytesSent %elapsedTime "%header{User-Agent}" %header{remote_user}</pattern>

...and then save the file, and restart Nexus Repository 3.

With this pattern, each line will print the value of the remote_user header at the end. If the request is successfully mapped to a valid user, then the third field on each line ( %user ) will print the same user ID.

Example: Reverse Proxy Terminating HTTPS on port 443

Reverse proxies must send special x-forwarded headers to Nexus Repository 3 in order for requests to work properly. Change the logback-access.xml pattern value so that additional inbound request headers relevant to reverse proxies are printed:

  <pattern>%clientHost %l %user [%date] "%requestURL" %statusCode %bytesSent %elapsedTime "%header{User-Agent}" %header{host} %header{x-forwarded-host} %header{x-forwarded-proto}</pattern>

...and then save the file, and restart Nexus Repository 3.

If your reverse proxy is configured correctly, then each line should look similar to:

192.168.2.110 - - [13/Dez/2016:14:41:45 +0100] "POST /service/extdirect/poll/rapture_State_get HTTP/1.1" 200 77 16 nexus.example.com - https

or possibly

192.168.2.110 - - [13/Dez/2016:14:41:45 +0100] "POST /service/extdirect/poll/rapture_State_get HTTP/1.1" 200 77 16 nexus.example.com nexus.example.com https

If request log lines do not end in https ( and instead just - ), then the reverse proxy is not sending the expected X-forwarded-proto HTTP request header that Nexus Repository 3 needs if the reverse proxy is terminating a HTTPS connection.

Related articles