aws application load balancer

[Stevenson Gossage]

Hi all,

We seem to be having problems with our ALB. The ALB listens on port 3500 which is the target for all requests for our domain routed via the perimeter firewall. The problem seems to be that the port number (3500) gets added to subsequent requests. For example when using the Hal browser, there is no issue loading the initial page and then making Get on any of the API endpoints, you will get a 200. However, if the call returns for example a list and you can then do subsequent Gets then, the new request will contain the 3500 port in the request and will timeout.

Here is the output from the console:

target url changed to: https://ospr.g.ent.cloud-nuage.canada.ca/server/api/core/bitstreamformats

and the response header has the following:

1. 1. Request URL:
      https://ospr.g.ent.cloud-nuage.canada.ca/server/api/core/bitstreamformats
   2. Request Method:
      GET
   3. Status Code:
      200
   4. Remote Address:
      3.96.93.249:443
   5. Referrer Policy:
      strict-origin-when-cross-origin
2. Response Headers
   1. cache-control:
      no-cache, no-store, max-age=0, must-revalidate
   2. content-language:
      en
   3. content-type:
      application/hal+json;charset=UTF-8
   4. date:
      Sat, 10 Sep 2022 02:59:10 GMT
   5. expires:
      0
   6. pragma:
      no-cache
   7. strict-transport-security:
      max-age=31536000 ; includeSubDomains
   8. vary:
      Origin
   9. vary:
      Access-Control-Request-Method
   10. vary:
       Access-Control-Request-Headers
   11. x-content-type-options:
       nosniff
   12. x-frame-options:
       DENY
   13. x-xss-protection:
       1; mode=block
3. Request Headers
   1. :authority:
      ospr.g.ent.cloud-nuage.canada.ca
   2. :method:
      GET
   3. :path:
      /server/api/core/bitstreamformats
   4. :scheme:
      https
   5. accept:
      application/hal+json, application/json, */*; q=0.01
   6. accept-encoding:
      gzip, deflate, br
   7. accept-language:
      en-US,en;q=0.9

Then is if you ask for next:

target url changed to: https://ospr.g.ent.cloud-nuage.canada.ca:3500/server/api/core/bitstreamformats?page=1&size=20

GET https://ospr.g.ent.cloud-nuage.canada.ca:3500/server/api/core/bitstreamformats?page=1&size=20 net::ERR_CONNECTION_TIMED_OUT
send @ jquery.min.js:2
ajax @ jquery.min.js:2
HAL.Http.Client.get @ client.js:95
resourceRoute @ browser.js:57
execute @ backbone.js:1700
(anonymous) @ backbone.js:1688
(anonymous) @ backbone.js:1971
Or @ underscore-min.js:6
loadUrl @ backbone.js:1969
checkUrl @ backbone.js:1959
hashchange (async)
followLink @ links.js:19
dispatch @ jquery.min.js:2
v.handle @ jquery.min.js:2

jquery.min.js:2 

XHR failed loading: GET "https://ospr.g.ent.cloud-nuage.canada.ca:3500/server/api/core/bitstreamformats?page=1&size=20".

  

Thanks very much for any help,

Stevenson

[Stevenson Gossage]

**UPDATE -- NOW WORKING**

Hello all,

Problem solved, we are not 100% sure if everything we did was needed, but each of the below changes that we made seemed to get us a step closer so here is what we did:

1. httpd.conf added :

ServerName ospr.g.ent.cloud-nuage.canada.ca:443

<VirtualHost _default_:80>
  ProxyPreserveHost On
  Header add X-Forwarded-For "ospr.g.ent.cloud-nuage.canada.ca"
  RequestHeader set X-Forwarded-For "ospr.g.ent.cloud-nuage.canada.ca"
  Header add X-Forwarded-Proto: "https"
  RequestHeader set X-Forwarded-Proto "https"
  Header add X-Forwarded-Port "443"
  RequestHeader set X-Forwarded-Port "443"
  Header add Host "ospr.g.ent.cloud-nuage.canada.ca"
  RequestHeader set Host "ospr.g.ent.cloud-nuage.canada.ca"
  ServerName ospr.g.ent.cloud-nuage.canada.ca:443
  ProxyPass /server http://private IP:8080/server
  ProxyPassReverse /server http:private IP:8080/server
</VirtualHost>

2. In locl.cfg added:

 server.use-forward-headers=true (needed for proxy (httpd) when using X-Forwarded-For and X-Forwarded-Proto headers)

We also added few FQDN in the rest.cors.allowed-origins but I don't believe they were necessary

If you have any thought, suggestion or question about what we did to make this work please let us know 

Thanks,

Stevenson

[Tim Donohue]

Hi Stevenson,

If the REST API URL is changing in your next request, it might​ be a configuration issue in your backend's local.cfg.  

I'd recommend checking the "_links" URLs that the REST API returns after the first request.  If you see the port 3500 listed there, then it could be that your "dspace.server.url" setting includes that port.

That's my best guess here is that you may have port 3500 listed in one of your configs in local.cfg which is confusing DSpace into thinking the next request should go to that port.  But, if that's not the case, then it's possible there's some undiscovered bug here in how DSpace is parsing requests from the AWS application load balancer  (I will admit, I have no experience here with ALB, so I don't have any ideas...but if this is the core issue, maybe others will respond with clues)

Tim

---

From: dspace...@googlegroups.com <dspace...@googlegroups.com> on behalf of Stevenson Gossage <stevenson....@gmail.com>
Sent: Friday, September 9, 2022 10:09 PM
To: DSpace Developers <dspace...@googlegroups.com>
Subject: [dspace-devel] aws application load balancer

 

--
All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
---
You received this message because you are subscribed to the Google Groups "DSpace Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-devel/0bf995d8-77b1-47e2-ace8-6cb8dc35319fn%40googlegroups.com.