HTTPS being overridden to HTTP

[divyanshverma]

Environment:
Server: Nodejs, Express

Everything works as expected over http. However over https, it rewrites the protocol to http:

See the image below. The request was made over https but Location headers is http. This creates the mixed content issue and access problems.

[Murderlon]

I think it works as expected currently? @tus/server doesn't have built-in TLS, so it will always be HTTP. If you put a HTTPS reverse-proxy in front of it, then your website will hit that and you won't have mixed content issues.

[andywirv]

I also hit the error with the Location header switching to HTTP with the service behind an HTTPS Load Balancer. The initial create request will work over HTTPS but the upload fails as it relies on the value returned in the Location header.
Setting options.relativeLocation: true made this work as no scheme is included in the Location header
https://github.com/tus/tus-node-server/tree/main/packages/server#optionsrelativelocation

[Murderlon]

AFAIK when running behind a reverse-proxy, it's better to let the proxy add X-Forwarded-Proto and the server will respect it (respectForwardedHeaders), rather than adding an another option to force override it regardless of the presence of a proxy.

What do you think?

[andywirv]

Relative location works well and I can't think of a downside to using it. Am I missing one(or many 😅)?

That said, respectForwardedHeaders is clearly there and documented for this purpose as you suggest. I just missed it. Easy to configure on Nginx and is included by default on GCP Load Balancers.

https://cloud.google.com/load-balancing/docs/https#target-proxies

Maybe a little more effort in k8s ingress-nginx.

[Murderlon]

Relative location works well and I can't think of a downside to using it. Am I missing one(or many 😅)?

I meant more rather than introducing a new option, like forceHttpsLocation or so, it's better to use X-Forwarded-Proto. If your use case is fine with relative location, then that's okay too!

So this issue can be closed then? I'm also okay with clarifying the docs if something is unclear.

[andywirv]

Works fine for me either way. Thanks
I didn't create the original issue but I think it is safe to close as no word from @divyanshverma

[XavierJordaMurria]

I know this has been closed,
I am facing a similar issue here.
my POST request goes via HTTPS and succeeds but the following PATCH is switched to HTTP and it fails.
locally when working just with HTTP it works fine.

Could you please explain how I could update the tus-node-server so it uses the current protocol and not just HTTP?

many thanks

[Murderlon]

See these previous comments: #469 (comment) and #469 (comment)

[D2rTech]

@Murderlon - my issue #550 is marked as duplicate, but we used respectforwardheader option and issue still persist.
What are the options now?

[andywirv]

@D2rTech what is the setup you are working with? If you are using https initially that means one or more reverse proxies/load balancers (as tus server does not support tls)

If you check the headers sent between each layer you will likely find the issue. When the headers mentioned above are sent it should work. Log the headers received by tus-server