Proxy prefix and 'No route matches [GET] "/"'

[Will Martin]

We're attempting to set up a sandbox copy of ArchivesSpace so that we can do some customization without touching the production copy. Due to circumstances beyond our control we cannot just set up a whole new VM for this sandbox: it needs to live on our existing development server, alongside a variety of other programs.

So far, we have successfully accomplished the following:

1. Set up a database. We're using MariaDB, because that's what production is running on. This part went fine.
2. Set up a Solr instance. This part went fine.
3. Installed ArchivesSpace.

We followed the directions for setting up a proxy prefix from the AS tech docs, and it appears to work. Mostly. Sort of.

The problem is that somewhere along the line, ArchivesSpace is losing track of what page to load.  When we attempt to access it, we get the following error message in the ArchivesSpace log:

F, [2025-11-07T14:10:10.883655 #464381] FATAL -- :
ActionController::RoutingError (No route matches [GET] "/"):

We have gone around and around and around trying to figure out how to get this thing to work.  The log files say that the connections to the database and the solr instance are working.  And the fact that we're getting the error message in the AS log means that Apache is correctly handling the reverse proxy stuff. The request comes in, and is being sent to AS.  And then it dies.

Our config.rb is as follows:

# Set database credentials
AppConfig[:db_url] = "jdbc:mysql://localhost:3306/archives_space?user=redacted&password=redacted"

# Specify where to find Solr
AppConfig[:solr_url] = "http://localhost:8983/solr/archivesspace"

# Reduce the number of logged messages
AppConfig[:frontend_log_level] = "error"
AppConfig[:backend_log_level] = "error"
AppConfig[:pui_log_level] = "error"
AppConfig[:indexer_log_level] = "error"

# Change the default admin password
AppConfig[:default_admin_password] = "redacted"

# We explicitly specified this because in an
# earlier revision port 8080 was not available.
# It's redundant now.
AppConfig[:frontend_url] = "http://localhost:8080"

# Set the correct URLs for the staff/public interfaces
AppConfig[:frontend_proxy_url] = "https://dev.library.und.edu/as/staff"
AppConfig[:public_proxy_url] = "https://dev.library.und.edu/as"

#AppConfig[:frontend_proxy_prefix] = proc { "#{URI(AppConfig[:frontend_proxy_url]).path}/".gsub(%r{/+$}, "/") }
#AppConfig[:public_proxy_prefix] = proc { "#{URI(AppConfig[:public_proxy_url]).path}/".gsub(%r{/+$}, "/") }

That's a complete copy of everything in the config; everything else we're just using the defaults.

Here are the relevant bits of our Apache configuration for the proxy pass through:

    # Redirect all traffic for the /solr folder to :8983 instead.
     ProxyPass /solr http://localhost:8983/solr
     ProxyPassReverse /solr http://localhost:8983/solr

    # Redirect all traffic for the /as/staff folder to :8080 instead.
    # This is the staff interface for ArchivesSpace.
     ProxyPass /as/staff http://localhost:8080
     ProxyPassReverse /as/staff http://localhost:8080

    # Redirect all traffic for the /as folder to :8081 instead.
    # This is the public interface for ArchivesSpace.
     ProxyPass /as http://localhost:8081
     ProxyPassReverse /as http://localhost:8081

We've tried every variation we can think of with the slashes at the end here -- no trailing slashes, trailing slashes on everything, trailing slashes on the ProxyPassReverse but not the ProxyPass, and the other way around -- all to no avail. The traffic appears to be getting direct to ArchivesSpace correctly, and then the router in AS just can't figure out what the heck page to load.

We've tried putting in more complete URLs by adjusting copies of the production stuff, like so:

https://dev.library.und.edu/as/repositories/2/resources/281

Which generates an error like so:

F, [2025-11-07T14:32:44.321777 #464381] FATAL -- : [e27a6c05-29a9-469a-97a3-7d1b875d3170]
[e27a6c05-29a9-469a-97a3-7d1b875d3170] ActionController::RoutingError (No route matches [GET] "/repositories/2/resources/281"):
[e27a6c05-29a9-469a-97a3-7d1b875d3170]

We've checked the archives of this user group, and found some people with similar error messages, but their solutions did not help.

We've been at it for two weeks now, and basically, we're stumped. Short of cracking open .war files and doing some low level debug, I'm not sure what else to try. So I thought I would ask here before dusting off the code editor.

Will Martin

Head of Digital Initiatives, Systems and Services

Chester Fritz Library

University of North Dakota

[Blake Carver]

Though I can't say I've tried it, I'm not sure you can do this:

AppConfig[:frontend_proxy_url] = "https://dev.library.und.edu/as/staff"

The "/as/staff" part. I'd stick with something like "/as/" for the pui and "/staff/" for the staff. 

It may actually work, but I wouldn't be surprised if it causes trouble.

I'd at least start with changing that ,  maybe (if possible) trying URLs with no prefix, like  staff-dev.library.und.edu and dev.library.und.edu for staff / pui URLs.

---

From: archivesspac...@lyrasislists.org <archivesspac...@lyrasislists.org> on behalf of Will Martin <william....@und.edu>
Sent: Friday, November 7, 2025 3:40 PM
To: Archivesspace_Users_Group <archivesspac...@lyrasislists.org>
Subject: [ArchivesSpace Users Group] Proxy prefix and 'No route matches [GET] "/"'

 

You don't often get email from william....@und.edu. Learn why this is important

--
You received this message because you are subscribed to the Google Groups "Archivesspace_Users_Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to Archivesspace_User...@lyrasislists.org.
To view this discussion visit https://groups.google.com/a/lyrasislists.org/d/msgid/Archivesspace_Users_Group/292c83af-4298-4110-a6bc-5d19c2e7ceban%40lyrasislists.org.

[Will Martin]

I can report that changing the proxy prefix for the staff interface from "/as/staff" to "/staff" had no effect. We got the same error message.

I'm not surprised -- the public user interface has the same problem, and it was just on /as.  But  it was worth a shot.

Will

[Will Martin]

I did some further experimenting, and had a thought: what if I try accessing AS directly, from the command line, without involving Apache at all?  Say, by trying to retrieve the home page using a wget command. If this problem was related to the Apache configuration, then the system would be happy to give me the HTML for the home page when Apache wasn't involved.  Right?

So I tried it.  And here's what I got:

[wmartin@dev ~]$ wget http://localhost:8080
--2025-11-07 16:42:01--  http://localhost:8080/
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:8080... connected.
HTTP request sent, awaiting response... 404 Not Found
2025-11-07 16:42:01 ERROR 404: Not Found.

Huh.

So I tried stripping the config.rb down to a bare minimum: the database credentials, the solr connection string, and nothing else.  And it worked!  Running wget got me the home page, neat as you please.

So then I tried re-enabling lines in the config.rb one at a time, restarting after each change.  As soon as I enabled the line containing the frontend_proxy_url, it started throwing 404 errors when I ran wget.

After that I tried setting the frontend_proxy_url to a variety of different values.  I tried it with "/staff".  I tried it with "/cute_cats".  I tried it where the entire value of the setting was the word "hi".  As far as I can tell, any time there is anything in that configuration directive, ArchivesSpace starts throwing 404 errors for every single path in the system.

At this point, I kind of wonder if this might be a bug. I know that hosting AS using a reverse proxy is not the generally recommended configuration.  It's possible that at some point a bug was introduced in the router code that hasn't gotten caught yet.

I'm going to file a bug report on GitHub. In the meantime, we'll use the awkward workaround -- namely, setting up an SSH tunnel using PuTTY so that we can point our browsers at http://localhost:8080 and have Putty silently serve as an endpoint to the actual destination on the server. I tried that and it works. It's just clunky.

Will