Tastypie POST request returns a non-SSL location header

Question

I am making a POST request for my Tastypie api that creates a resource. It usually returns the uri resource through the Location header in the response. The problem I ran into is that the Location header contains a non-ssl url, although my initial request (and my entire application) is under https.

From my request headers:

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

From my answer headers:

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

Since this is a reusable application that does not always run under ssl, I don’t want to hardcode the ugly string. In addition, there are already 301 redirects in place, from http to https, but I do not want the redirect to occur.

All help appreciated!

Update: This actually had nothing to do with Tastypie, it was due to the server / proxy configuration. See the answer below for more details.

Answer 1

The reason is simple: it would seem that request.is_secure() returns False in your case, so the URL is created using http instead of https .

There are several solutions, but you must first find what called request.is_secure() to return False . I bet you work on some proxy server or load balancer. If you have not changed the logic for creating URLs, this is probably the cause of your problem.

To fix this, you can look at SECURE_PROXY_SSL_HEADER in Django , which defines headers indicating the SSL connection established using a proxy or load balancer:

If your Django application is behind a proxy server, the proxy server can “swallow” the fact that the request is HTTPS using a non-HTTPS connection between the proxy server and Django. In this case, is_secure() will always return False - even for requests that were made via HTTPS by the end user.

In this situation, you want to configure your proxy server to set a custom HTTP header that tells Django whether the request came through HTTPS, and you want to set SECURE_PROXY_SSL_HEADER so that Django knows what the header looks like.

But if you are developing a reusable application, and in your case it is correct, just make sure that it is not something else. If you are sure that this is so, then leave it to the user - the headers responsible for specifying the request safely should be set explicitly, only by the programmer who uses your application. Otherwise, this may indicate a security problem.