HTTPS being overridden to HTTP about tus-node-server HOT 10 CLOSED

@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

from tus-node-server.

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.

from tus-node-server.

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

from tus-node-server.

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?

from tus-node-server.

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.

from tus-node-server.

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.

from tus-node-server.

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

from tus-node-server.

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

from tus-node-server.

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

from tus-node-server.

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

from tus-node-server.