I'm trying to add rules to my listener in an ALB. The host headers are of the form:
example-1.com
example-2.com
example-3.com
Can we use a wildcard for this kind of host header, like this:
example-*.com
Are wildcard characters (*, ?) allowed in the middle of the url or path?
From this blog post from 2017, it appears that you can.
You can create Application Load Balancer rule that routes incoming traffic based on the domain name specified in the Host header
Rules that match the Host header can include up to three “*” (match 0 or more characters) or “?” (match 1 character) wildcards.
Reference
Related
This is a relatively recent behavioral change and appears to be related only to requests which include a "Upgrade-Insecure-Requests: 1" request header.
Apache has started rewriting such requests for sites which are HTTP-only to an HTTPS URL using the default site name instead of just adding the / at the end of the requested URL.
Example: URL submitted in browser: http://www.example.com/blah
Intended redirect: 301 to http://www.example.com/blah/
Instead redirects: 301 to https://default.site.configured/blah/
This happens whether it's a named virtual on the same address as the default server or a virtual using a separate address with separate Listen directives.
I understand all the arguments in favor of the idea that everything should always be encrypted and I don't want to get into a debate about that. This site doesn't consider the tradeoffs desirable at this time.
The default site does have SSL and is configured to redirect HTTP->HTTPS, but the www.foo.com site is not configured that way and does not wish to implement SSL at this time.
Is there any way to get Apache 2.4 to disregard that "Upgrade" header and simply rewrite the URL as desired rather than altering the domain name?
After banging on this some more, I finally found the source of my woes.
This happens when you have IP based virtual hosts and did not configure a name for them using the "ServerName" directive.
tl;dr: If you are having this problem, try adding a "ServerName www.example.com" directive within the VirtualHost definition for the site and that should resolve it.
Details:
It does not happen until you encounter a URL that requires a rewrite other than adding a trailing /. (i.e. if you get a request that doesn't contain the "Upgrade-Insecure-Requests: 1" header, it only gets the trailing / added, but if you get one with that header, it also tries to rewrite the protocol to https which triggers the full URL rewrite).
In my case, the default host name had an SSL configuration, so it didn't fall back to HTTP after the rewrite or reject the rewrite as invalid.
YMMV, I did not continue to do an exhaustive test of all permutations once I found the solution.
I came across an IP address / unknown bot that made four HTTP requests, managing to request four different domain names in the following fashion without the first character being a forward slash /:
"GET www.example.com
When I make test the request http://localhost/www.example.com I see the following in Apache:
"GET /www.example.com
All other requests start with a forward slash. How did the bot manage to make such a request and how can I reproduce this to determine how to handle such requests?
Quoted Apache logs reduced to request method and URL to avoid off-topic comments.
Based on the way HTTP requests work, this can be achieved by sending a raw HTTP request to your IP address and specifying both the GET and Host headers as described on the linked page above:
The most common form of Request-URI is that used to identify a
resource on an origin server or gateway. In this case the absolute
path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
the Request-URI, and the network location of the URI (authority) MUST
be transmitted in a Host header field. For example, a client wishing
to retrieve the resource above directly from the origin server would
create a TCP connection to port 80 of the host "www.w3.org" and send
the lines:
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the
original URI, it MUST be given as "/" (the server root).
This can be done on Windows using PuTTY, or on Linux/Mac using nc (see answer here for more details: https://stackoverflow.com/a/3620596/1038813)
How do I set up another Host Header in the cloudflare worker?
For example, I have set up a 1.2.3.4 ip for my site's www record
By default www requests are sent with the header www.ex.com but I want to send the www requests with the new.ex.com header
You need to configure a DNS record for new.ex.com so that it points to the same IP address. Then, you can make a fetch() request with new.ex.com in the URL.
If you cannot make new.ex.com point at the right IP, another alternative is to make a fetch() request using the resolveOverride option to specify a different hostname's IP address to use:
fetch("https://new.ex.com", {cf: {resolveOverride: "www.ex.com"}});
Note that this only works if both hostnames involved are under your zone. Documentation about resolveOverride can be found here.
You cannot directly set the Host header because doing so could allow bypassing of security settings when making requests to third-party servers that also use Cloudflare.
// Parse the URL.
let url = new URL(request.url)
// Change the hostname.
url.hostname = "check-server.example.com"
// Construct a new request
request = new Request(url, request)
Note that this will affect the Host header seen by the origin
(it'll be check-server.example.com). Sometimes people want the Host header to remain the same.
// Tell Cloudflare to connect to `check-server.example.com`
// instead of the hostname specified in the URL.
request = new Request(request,
{cf: {resolveOverride: "check-server.example.com"}})
I recently started experimenting with traefik and I'm swiching over from nginx.
I'm a bit confused by how the paths in Path, PathStrip, PathPrefix and PathPrefixStrip work regarding trailing slashes.
In nginx for proxied requests this is the documentation:
If a location is defined by a prefix string that ends with the slash
character, and requests are processed by one of proxy_pass,
fastcgi_pass, uwsgi_pass, scgi_pass, or memcached_pass, then the
special processing is performed. In response to a request with URI
equal to this string, but without the trailing slash, a permanent
redirect with the code 301 will be returned to the requested URI with
the slash appended. If this is not desired, an exact match of the URI
and location could be defined like this:
location /user/ {
proxy_pass http://user.example.com;
}
location = /user {
proxy_pass http://login.example.com;
}
How would it be possible to replicate this behaviour?
Essentially I’d like traefik to append the trailing slash when not present, so that PathPrefixStrip:/mylocation/ will also match /mylocation and issue a 301 for /location/.
In addition I'm a bit confused by the difference between Path and PathPrefix when used as Modifiers, is there some documentation that explains the difference in their respective behaviour?
Thank you.
This question is old, still helpful for novice traefik users.
This question was probably related with traefik 1.x, here the official matchers documentation for 1.7
It stands:
Path: /products/, /articles/{category}/{id:[0-9]+} Match exact request path. It accepts a sequence of literal and regular expression paths.
...
PathPrefix: /products/, /articles/{category}/{id:[0-9]+} Match request prefix path. It accepts a sequence of literal and regular expression prefix paths.
Also their are very clear about path Path Matcher Usage Guidelines
But this is old and deprecated in favor of the current version. So check the latest documentation
The traefik is very different on 2.x version. You can check the migration guide here
Now you need to setup:
entrypoints
routers
middlewares
services
In your router, the rule property is where your set the Path or PathPrefix matcher. The rule reference are here
Path(/path, /articles/{cat:[a-z]+}/{id:[0-9]+}, ...) Match exact request path. It accepts a sequence of literal and regular expression paths.
PathPrefix(/products/, /articles/{cat:[a-z]+}/{id:[0-9]+}) Match request prefix path. It accepts a sequence of literal and regular expression prefix paths.
Is there a wildcard for any top level domain in .htaccess for Access-Control-Allow-Origin?
I want to allow all top level domains (and any subdomain) of *.example.*.
So: example.com, example.org, any.example.com ...
Currently it works with:
SetEnvIf Origin ^(https?://.+\.example\.com(?::\d{1,5})?|https?://.+\.example\.org(?::\d{1,5})?)$ CORS_ALLOW_ORIGIN=$1
Header append Access-Control-Allow-Origin %{CORS_ALLOW_ORIGIN}e env=CORS_ALLOW_ORIGIN
Header merge Vary "Origin"
You can't specify a partial wildcard in the response.
You need to write code which examines the Origin request header, checks that it is acceptable and then echos it back in the response.