Http Redirection of URN responds with a wrong Protocol and format

[cessda-bitbucket-importer]

Original report on BitBucket by Joshua Tetteh Ocansey (GitHub: Joshocan).

---

• HTTP redirection of URNs responds with HTTP instead of HTTPS
• The format of the redirection URL location is not the recommended format:

location:  http://vocabularies.cessda.eu:80/vocabulary/CdcPublisherNames?v=5.0

it shoud rather be:

location:  https://vocabularies.cessda.eu/vocabulary/CdcPublisherNames?v=5.0

‌

• For example, A redirection for URN https://vocabularies.cessda.eu/urn/urn:ddi:int.cessda.cv:CdcPublisherNames:5.0 response as shown below:

Joshuas-iMac:jira-to-zenhub-migration Joshocan$ curl -I https://vocabularies.cessda.eu/urn/urn:ddi:int.cessda.cv:CdcPublisherNames:5.0
HTTP/2 301 
expires: 0
cache-control: no-cache, no-store, max-age=0, must-revalidate
pragma: no-cache
location: http://vocabularies.cessda.eu:80/vocabulary/CdcPublisherNames?v=5.0
referrer-policy: strict-origin-when-cross-origin
content-security-policy: default-src 'self' https://cdn.matomo.cloud https://cessda.matomo.cloud https://analytics.cessda.eu; frame-src 'self' https://cdn.matomo.cloud https://cessda.matomo.cloud https://cessda.atlassian.net data:; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://cdn.matomo.cloud https://cessda.matomo.cloud https://cessda.atlassian.net https://analytics.cessda.eu https://storage.googleapis.com; style-src 'self' https://fonts.googleapis.com 'unsafe-inline'; img-src 'self' https://cdn.matomo.cloud https://cessda.matomo.cloud https://cessda.atlassian.net https://analytics.cessda.eu data:; font-src 'self' https://fonts.gstatic.com data:
date: Tue, 13 Sep 2022 14:20:40 GMT
vary: Origin
vary: Access-Control-Request-Method
vary: Access-Control-Request-Headers
feature-policy: geolocation 'none'; midi 'none'; sync-xhr 'none'; microphone 'none'; camera 'none'; magnetometer 'none'; gyroscope 'none'; speaker 'none'; fullscreen 'self'; payment 'none'
content-length: 0
strict-transport-security: max-age=31536000
x-content-type-options: nosniff
x-frame-options: sameorigin
x-xss-protection: 1

‌

[cessda-bitbucket-importer]

Original comment by Taina Jääskeläinen.

---

Machine-end issue, not end-user issue.

[cessda-bitbucket-importer]

Original comment by Martin Šeleng (GitHub: pakoselo).

---

@Joshocan I don not understand why this happens, as the code is that it receives the protocol from the header of the request, and it is https://. I locally deployed the ssl version of cessda vocabulary service and it works as it should. The problem is maybe in the deployment of the production service to the cloud. It should work as desired without any hacking. I can override the port and https in a hard way but it is a huge hack.

‌