POST request to Tastypie returns a non-SSL Location Header

Question

I am doing a POST request to my Tastypie api, which creates a resource. It normally returns the resource uri, through the Location header in the response. The problem I'm having is the Location header contains a non-ssl url, even though my initial request (and the whole of my application) is under https.

From my request headers:

URL: https://example.com/api/v1/resource/

From my response headers:

Location: http://example.com/api/v1/resource/80/

Because this is a reusable application that is not always running under ssl, I do not want to hardcode an ugly string replace. Also, there is already a 301 redirect in place, from http to https, but I do not want the redirect to happen.

All help appreciated!

Update: This actually didn't have anything to do with Tastypie, it was because of the servers/proxy configuration. See answer below for resolution details.

Answer 1

The reason is simple: seemingly request.is_secure() returns False in your case, so the URL is constructed using http instead of https .

There are couple of solutions, but you should first find what caused request.is_secure() to return False . I bet you are running behind some proxy or load balancer. If you did not change the logic behind URL generation, then this is probably the cause of your issue.

To fix that, you can take a look at SECURE_PROXY_SSL_HEADER setting in Django , which defines headers that indicate the SSL connection established with the proxy or load balancer:

If your Django app is behind a proxy, though, the proxy may be "swallowing" the fact that a request is HTTPS, using a non-HTTPS connection between the proxy and Django. In this case, is_secure() would always return False -- even for requests that were made via HTTPS by the end user.

In this situation, you'll want to configure your proxy to set a custom HTTP header that tells Django whether the request came in via HTTPS, and you'll want to set SECURE_PROXY_SSL_HEADER so that Django knows what header to look for.

But if you are designing a reusable app and the above is correct in your case, just make sure it is not something different. If you are sure this is the case, then leave that to the user - the headers responsible for secure request indication should be set explicitly, only by the programmer who uses your app. Otherwise this could mean a security issue.