Using Apache in front of DSpace: accessing items by handle/DOI causes Apache 500 or 504 errors

[Agustina Martinez-Garcia]

Hi all,

We are testing DSpace 8.1 and have a set up where we use Apache server as a proxy. We have noticed that when accessing URLs to items, cols, comms by their handle OR when resolving DOIs into items we get errors from Apache (500 or sometime 504s).

A few months ago we performed changes to our Apache configs to start using the MPM event module to improve performance instead of the default Prefork. Our production DSpace 7.6.1 instance does not present these issues when using the event module, but the DSpace 8.1 server does. We can confirm that switching back to using prefork resolves the issue.

Errors we see in apache are not very useful (below) and there are no errors at the DSpace end (frontend and backend).

[Tue Jun 10 12:48:34.853769 2025] [proxy_http:error] [pid 864881:tid 133347774826176] (20014)Internal error (specific information not available): [remote 172.22.88.52:58112] AH01102: error reading status line from remote server localhost:4000, referer: https://dspace8-f-dev.lib.cam.ac.uk/items/750a9345-cb0f-44f9-9aa6-797ab42ba079

I wanted to check if anyone else with this setup is seeing this behaviour.

Thanks!
Agustina

[mw...@iu.edu]

504 is "gateway timeout": your front-end NodeJS processes are not
responding quickly enough, or not responding at all. dspace-angular
produces floods of log data, so maybe there is a clue there.

You can get more details about the HTTPD side of the failure by
increasing the LogLevel for 'proxy' and 'proxy_http'. Level TRACE8
will produce large quantities of records about how proxy connections
are being made, used and torn down. But I would look at the front-end
logs first.

--
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
library.indianapolis.iu.edu

[Agustina Martinez-Garcia]

Hi Mark,

Thanks so much for the information, the loglevel settings are useful!

All the errors we are now seeing are always 500 internal error, the 502 may have been temporary and something else.

When looking at the angular logs, we see lots of errors like this:

ERROR Error: Cannot set headers after they are sent to the client

15|dspace- |     at new NodeError (node:internal/errors:405:5)

15|dspace- |     at ServerResponse.setHeader (node:_http_outgoing:655:11)

15|dspace- |     at ServerResponseService2.setHeader (/home/dspace/apollo-dspace-angular/dist/server/main.js:1:591326)

15|dspace- |     at Object.next (/home/dspace/apollo-dspace-angular/dist/server/6144.js:1:207142)

15|dspace- |     at ConsumerObserver2.next (/home/dspace/apollo-dspace-angular/dist/server/main.js:1:3418988)

15|dspace- |     at SafeSubscriber2.Subscriber2._next (/home/dspace/apollo-dspace-angular/dist/server/main.js:1:3418350)

15|dspace- |     at SafeSubscriber2.Subscriber2.next (/home/dspace/apollo-dspace-angular/dist/server/main.js:1:3417787)

15|dspace- |     at /home/dspace/apollo-dspace-angular/dist/server/main.js:1:3433595

15|dspace- |     at OperatorSubscriber2._this._next (/home/dspace/apollo-dspace-angular/dist/server/main.js:1:3464242)

15|dspace- |     at OperatorSubscriber2.Subscriber2.next (/home/dspace/apollo-dspace-angular/dist/server/main.js:1:3417787) {

15|dspace- |   code: 'ERR_HTTP_HEADERS_SENT'

I have also been looking further at our Apache settings and I noticed that we had "keepalive" disabled, which may have been a hangover of older configurations when we were still using mpm_prefork. When enabling the keepalive setting, I can confirm that the 500 errors reduce drastically although we still see them occasionally, as well as partial load of the item pages following the redirect from the handle URL at times.

Best and thanks!

Agustina