We are using nginx for load balancing and handling SSL of an API. Requests are forwarded to Tomcat instances. Since Tomcat does not use SSL, all hyperlinks that are provided by Tomcat use http rather than https.
We use module ngx_http_sub_module to modify all hyperlinks in the response body and replace http by https. This is working already.
However, all hyperlinks in the response header, for example in the Location or Link headers are not replaced.
Is there any other module that can be used for this purpose?
See the proxy_redirect directive. For more complicated proxying, getting this setting correct gets difficult, but for simpler cases their provided examples should prove illuminating.
I still haven't found a way to handle Link: headers reliably.
Related
I use wicket 8.10, it is installed on tomcat and proxied by nginx. SSL certificates configured in nginx config. Also Nginx forwards all HTTP requests to HTTPS.
The problem is following:
When I submit any form wicket returns response headers where the Location tag contains url with HTTP protocol.
Why it is important:
The last chrome update makes browser show alert when Location contains HTTP protocol on page opened by HTTPS. Before that, nginx quietly redirected the request, but now user see alert page from browser (similar to when certificate is invalid or absence).
The problem here is that your Wicket application does not know that it is behind a proxy.
There are two solutions:
use XForwardedRequestWrapperFactory
It will wrap the Tomcat's HttpServletRequest with one that reads X-Forwarded-*** request headers.
Just make sure that Nginx exports X-Forwarded-Proto request header
use HttpsMapper
Just overwrite protected Scheme getDesiredSchemeFor(Class<? extends IRequestablePage> pageClass) to return Scheme.HTTPS in PRODUCTION mode and Scheme.HTTP in DEVELOPMENT mode (I assume you don't use Nginx proxy while developing)
The simplest solution I have found is to use the nginx directive:
proxy_redirect http://example.com https://example.com;
It changes location header from http://example.com/any/path to https://example.com/any/path
I'm using nginx as a reverse proxy server.
My application servers behind it accept custom extension methods for requests.
For example, "MYMETHOD".
However the nginx default configuration seems to only accept non-extension methods, such as HEAD, GET, POST, etc, and returns a default nginx 400 response for requests that did not have a non-extension method, instead of proxying those requests to my app servers.
How can I make nginx accept and proxy any http requests regardless of their method?
I do not want to whitelist specific methods, because this would require me to change the nginx configuration every time I need to support a new method in my app servers, and I do not want those to be tightly coupled.
[edit]
The solution has to work for official supported nginx distributions, either on nginx.com or popular linux distributions (debian, centos, etc).
Obviously I can just alter the nginx source code and make it pass along any methods, but if I'm altering the source code and recompiling it's no longer nginx but rather a fork of it.
You can use ngx_http_allow_methods_module for allowing custom HTTP methods. This module allows arbitrary HTTP methods to be passed to a backend application.
Example:
http {
server {
location /api/ {
allow_methods ".*";
}
}
}
Directive
allow_methods "^(GET|POST|PUT|DELETE|PATCH|LINK|COPY)$";
This directive describes HTTP methods that should be passed along. The pattern is case-sensitive (as per RFC 2616). If it is absent, the default rules of Nginx apply. You should use this directive only in the locations that you really need it in.
We are working on SAP XS Advanced that is based on Cloud foundry and we got into a funny situation, we need an app to be HTTP only (I know it's not secure...but our situation requires it to be HTTP).
Does anyone know how to disable default deployment to HTTPS?
You can have your application check if the connection came in over HTTP or HTTPS and if it's the latter, you can redirect the user to HTTP. Normally, you'd do the opposite, but it should work this way too.
On Cloud Foundry, you can check if the connection is HTTP or HTTPS by examining the X-Forwarded-Proto header. That will tell you either http or https. Alternatively, you could look at X-Forwarded-Port which would tell you 80 or 443.
How you do this and how you issue the redirect depends entirely on the application, language and frameworks you're using. Some may handle this automatically, some may require manual configuration or code changes.
Hope that helps!
I've seen lot of software that tries to determine if current protocol is HTTP or HTTPS, mainly to output links and avoid the Mixed content error.
Usually the software checks some server variables (for example, $_SERVER['HTTP'] in PHP, see this question: PHP Get Site URL Protocol - http vs https).
This method may work, but fails for example when you have a reverse proxy that receives SSL traffic and requests content to a web server over HTTP (so when the software checks the HTTPS status it's off). Web server will response with HTTP links but content is actually server over HTTPS.
There's a simple solution for this: just use links without protocol: '//' instead of 'http://' or 'https://'.
So, my question is: is a better practice to detect current protocol (http or https) instead of just using default protocol for content links (CSS, JS, images, AJAX, etc)? If yes, why is this?
Using '//' works, but it means your resources must be available with http and https.
So you can simply use 'https://' so you are sure to always use the secure connection, and avoid mixed-content errors.
(Of course, the most secure option is to always use https, with a 301 redirect on http and HSTS)
I have an IIS6 ASP.NET 2/3.5 site that ALWAYS seems to be caching anything that goes through a https request. HTTP requests always work the same, but i see old/invalid data on https requests.
I see this a lot with pages where i'm doing http rewriting--but in general, it almost seems like the site has one set of values it shows to http requests and another to https requests-- without having any backend code that renders differently based upon the scheme.
Any ideas? Does IIS have a weird ssl caching option i'm not aware of?
The ports were set up wrong in IIS-- although the domain was correct because i was using port 443 it got forwarded to another site (because of host headers setup).