I have a URL (A) which responds with a cached resource and status code 304.
In Cloudflare, I've setup a forwarding URL page rule (temporary redirect) to forward A to the new URL (B). Unfortunately, this is not working. Is it possible that the 304 response is taking precedence?
Some additional notes:
Cloudflare Browser Cache Expiration setting is set to "Respect Existing Headers"
Cloudflare caching level is set to "Standard"
URL A and B are both on the same subdomain and the HTTP proxy is turned on
Set the HTTP Proxy on the DNS setting and be patient.
Related
I'm trying to redirect traffic from all services through an API Gateway. To be backward compatible I try to define a CNAME to redirect traffic to the API Gateway. As a result, I have a request coming to the subdomain of my API Gateway but with the Host header set to my service subdomain. Something like this: curl "https://gateway.example.com" -H "Host: myservice.example.com" Since the domain the and the Host are different, Cloudflare (proxied DNS) return 403 HTTP error, hinders the request from reaching the gateway.
Is there any way to relax this restriction while using Cloudflare proxy?
Did you have a look at the Origin Rules feature? One of the capabilities included allows to override the Host header of the incoming proxied request. You could use this to set the correct Host header your origin infrastructure is expecting based on the characteristic of the incoming request.
I have a simple worker that just does a fetch against an HTTPS endpoint somewhere else.
The code is literally just:
return await fetch('https://something.com/someResource')
When I test locally (wrangler dev) and even publish to a workers subdomain this works fine. When I curl https://foo.bar.workers.dev/myEndpoint I get the same response as https://something.com/someResource.
However I want to run this from my own domain (managed through cloudflare) so the worker also has a route of foo.mydomain.com/* and a AAAA record to 100:: for foo as per CloudFlare docs. The DNS works fine the URL is reachable, but when I try to hit https://foo.mydomain.com/myEndpoint CloudFlare's worker logs show that the fetch behind the scenes fails with a 525 error (SSL Handshake fail).
Things I've tried based on some CloudFlare forum posts:
Add a page rule foo.mydomain.com/* -> SSL Mode: full since my overall SSL settings are set to flexible.
Set the host header in the fetch to the origin domain ( fetch(url, {headers: {'Host': 'something.com'}})
FYI, I don't control the origin server as it's an external API I work with.
How come the same request works from local and *.workers.dev but not my own domain?
Your page rule is not taking effect. The page rule is for foo.mydomain.com/*, but it has to match the subrequest URL, which in this case is https://something.com/someResource, which doesn't match. It doesn't matter that the original worker request matched -- what matters, in this case, is whether the subrequest URL matched.
Unfortunately, you cannot create a page rule that matches a domain other than your own.
Instead, what you'll need to do is reverse things. Set your SSL mode to "full" by default, but then use page rules to set it to "flexible" for your own domain.
(Note: The "SSL Handshake fail" error itself is actually a known bug in Workers, that happens when you try to talk to a host outside your zone using HTTPS but you have "flexbile" SSL set. We do not use flexible SSL when talking to domains other than your own, but there's a bug that causes the request to fail instead of just using full SSL as it should.)
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 am trying to force browser to use https even when the user enters http URL. The idea is to use http response headers from the server. I am able to implement redirection using redirect (in site.conf) & Rewrite (which is disliked universally) but want to test out this method too.
Now I have tried adding the the following to my /etc/apache/sites-enabled/mysite.conf but despite the browser receiving the header response the user is not redirected to https (default apache page is shown):
Header set Location https://www.example.com/
Header set X-Forwarded-Proto: https
Header set Strict-Transport-Security "max-age=180; includeSubdomains"
Do I have to change anything else in the apache configuration to achieve this? (all modules are correctly loaded)
The Location header is only used for redirect responses (with a HTTP response code of 3XX) or Created responses (with a HTTP response code of 201):
https://www.rfc-editor.org/rfc/rfc7231#section-7.1.2
Just setting the header on a random page will not make the browser redirect.
When you use apache Redirect and Rewrite rules they set the response header AND add the location header. I really don't know why you'd want to do this manually.
And rewrite is not "universally disliked". It just overused when redirect would be simpler and more efficient in a lot of cases. If you need something more complicated then Rewrite is the right tool to use.
Finally you should not sent the Strict-Transport-Security header on a HTTP response (and the browser will rightly ignore it you do) but only on a HTTPS responses.
I have a website thats currently being accessed on an "https" url but the certificate is expiring soon and we do not want SSL on this website anymore so just an "http" access is fine. How do I get the requests made to https url automatically redirect to the http url? This page might have been bookmarked by people and the bookmark will still have the "https" url. I want these requests to be redirected to the "http" url. I am running my website on a Microsoft IIS.
Reply to the request with an HTTP 301: Moved Permanently.
I had a similar scenario, but in the opposite direction.
set your DNS Manager to point to same ip/machine for both http and https
on the iis machine, create a dummy web site for https that points it to http.