fix: API returns invalid file URLs, due to including the port

[BalduinLandolt]

Issue Number: DEV-1378

Pull Request Checklist

Basic Requirements

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix: represents bug fixes
• Refactor: represents production code refactoring
• Feature: represents a new feature
• Documentation: documentation changes (no production code change)
• Chore: maintenance tasks (no production code change)
• Style: styles updates (no production code change)
• Test: all about tests: adding, refactoring tests (no production code change)
• Other... Please describe:

Does this PR introduce a breaking change?

• Yes
• No

Does this PR change client-test-data?

• Yes (don't forget to update the JS-LIB team about the change)
• No

Other information

[swarmia]

✅  Linked to Bug DEV-1378 · DSP-APP: Project scenario-Tanner - wrong image display and 404 error on prod

[codecov]

Codecov Report

Base: 86.64% // Head: 86.87% // Increases project coverage by +0.23% 🎉

Coverage data is based on head (82529cf) compared to base (71c772f).
Patch coverage: 78.48% of modified lines in pull request are covered.

❗ Current head 82529cf differs from pull request most recent head 85aefc3. Consider uploading reports for the commit 85aefc3 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2223      +/-   ##
==========================================
+ Coverage   86.64%   86.87%   +0.23%     
==========================================
  Files         233      241       +8     
  Lines       28020    27994      -26     
==========================================
+ Hits        24277    24320      +43     
+ Misses       3743     3674      -69     

Impacted Files	Coverage Δ
...sp-shared/src/main/scala/dsp/valueobjects/V2.scala	84.05% <0.00%> (-1.45%)	⬇️
webapi/src/main/scala/org/knora/webapi/Main.scala	0.00% <0.00%> (ø)
...sponder/projectsmessages/ProjectsMessagesADM.scala	91.19% <ø> (ø)
...tore/triplestoremessages/TriplestoreMessages.scala	74.78% <ø> (-0.22%)	⬇️
...webapi/messages/util/ConstructResponseUtilV2.scala	93.29% <ø> (ø)
...a/org/knora/webapi/messages/util/MessageUtil.scala	36.66% <ø> (ø)
...vsearch/types/GravsearchTypeInspectionRunner.scala	100.00% <ø> (ø)
.../webapi/messages/v2/responder/KnoraRequestV2.scala	0.00% <ø> (ø)
...webapi/messages/v2/responder/KnoraResponseV2.scala	85.18% <ø> (ø)
...s/v2/responder/listsmessages/ListsMessagesV2.scala	90.54% <ø> (ø)
... and 124 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[mpro7]

Approved, but check my suggestion/section.

[mpro7]

Suggested change

	val internalBaseUrl: String =
	internalProtocol + "://" + internalHost + (if (internalPort != 80) ":" + internalPort else "")
	val externalBaseUrl: String =
	externalProtocol + "://" + externalHost + (if (externalPort != 80) ":" + externalPort else "")
	val internalBaseUrl: String = internalProtocol + "://" + internalHost
	val externalBaseUrl: String = externalProtocol + "://" + externalHost

Is the port needed here at all? If not then it should be shortened as above.

[BalduinLandolt]

hard to say, it might break locally, or in tests... But even if so, I do suspect that externalPort != 80 does not make sense, it should be 1024 if anything, because that's the config default, which should only happen when there is no environment variable set (and it's also what the docker-compose specifies, when ewe run it locally).
But I am reluctant to change these things now: Then we might not know what actually fixed the but. So IMO it would be best to only change what we expect to be the core issue, and then do a separate cleanup of all this stuff in a dedicated task. The same should also be done with all other configs, not only SIPI - but then we'll have to do much more testing, so we can't deploy the fix to prod anytime soon... Does that make sense?

[mpro7]

That means you are guessing a lot, but if you feel there is no other way to make sure what and if it works, then go ahead.

[BalduinLandolt]

yes... it's a guessing fix at that point (though there is a good chance this will actually fix it, we did do some testing). But the guessing thing only gets harder when we change more things, so I'd actually prefer it like this, I think.