Google has added a new defaultUrlRedirect feature to URL maps. It's supported both at the top level, and as part of a pathMatcher.
google_compute_url_mapThis shows creating a url_map and associated proxy and forwarding rule for an HTTP -> HTTPS redirect. It would be used in combination with an https proxy that hosted the site(s).
resource "google_compute_global_address" "some_address" {
name = "some-address"
}
resource "google_compute_global_forwarding_rule" "https_redirect" {
name = "https-redirect"
target = google_compute_target_http_proxy.https_redirect.self_link
port_range = "80"
ip_address = google_compute_global_address.some_address.self_link
}
resource "google_compute_target_http_proxy" "https_redirect" {
name = "https-redirect"
url_map = google_compute_url_map.https_redirect.self_link
}
resource "google_compute_url_map" "https_redirect" {
name = "https-redirect"
// This is the new feature here.
default_url_redirect {
https_redirect = true
}
}
@danawillow is this something that modular-magician will be able to take care of?
If not I could take a closer look and work on this since I really want to make use of this new feature (I've literally been waiting for this for years).
Since url_map is a generated resource, the feature addition would have to happen inside of MM, but nothing there actually happens automatically- it's just a different way to describe the API schema for a resource and remove some of the boilerplate that happens when adding features. So if you'd like, you're absolutely welcome to work on this- there's a README/codelab at https://github.com/GoogleCloudPlatform/magic-modules, or depending on your comfort level, you could browse through some merged PRs to see how new fields get added to existing resources. I imagine this one will be fairly straightforward.
It also looks like we're now able to define the redirect in the default host rule of an URL map, without defining a default backend service. So I think that the default_service attribute of the google_compute_url_map should be optional, to reflect this behavior.

It also looks like we're now able to define the redirect in the default host rule of an URL map, without defining a default backend service. So I think that the
default_serviceattribute of thegoogle_compute_url_mapshould be optional, to reflect this behavior.
The default_service is already optional: https://www.terraform.io/docs/providers/google/r/compute_url_map.html#default_service
@danawillow I've opened the PR over at GoogleCloudPlatform/magic-modules#3379
I tested it on a fresh Google Cloud project with the following manifest (also committed as an example in the PR) and it does what I expect:
provider "google" {
project = "*****"
region = "europe-west1"
}
resource "google_compute_global_forwarding_rule" "default" {
name = "global-rule"
target = google_compute_target_http_proxy.default.self_link
port_range = "80"
}
resource "google_compute_target_http_proxy" "default" {
name = "test-proxy"
url_map = google_compute_url_map.default.self_link
}
resource "google_compute_url_map" "default" {
name = "url-map"
default_url_redirect {
https_redirect = true
}
}
curl -v http://34.102.223.56:80/ ✓ 10236 20:03 2020-04-15
* Trying 34.102.223.56...
* TCP_NODELAY set
* Connected to 34.102.223.56 (34.102.223.56) port 80 (#0)
> GET / HTTP/1.1
> Host: 34.102.223.56
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Cache-Control: private
< Content-Type: text/html; charset=UTF-8
< Referrer-Policy: no-referrer
< Location: https://34.102.223.56/
< Content-Length: 219
< Date: Wed, 15 Apr 2020 18:03:49 GMT
<
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://34.102.223.56/">here</A>.
</BODY></HTML>
* Connection #0 to host 34.102.223.56 left intact
The
default_serviceis already optional: https://www.terraform.io/docs/providers/google/r/compute_url_map.html#default_service
Indeed, but it looks like compute API won't let us do this anyway:
Error: Error creating UrlMap: googleapi: Error 400: Invalid value for field 'resource.defaultService': ''. No default backend service specified., invalid
Maybe it's not possible to create an url map without any backend service at first, but it is possible to edit one after its creation an to remove this reference (as I did through the console actually).
@yannlambret oh well, yes: You can't just leave defaultService away! But it works well as soon as you specify the defaultUrlRedirect!
As the API docs state: If defaultUrlRedirect is specified, defaultService or defaultRouteAction must not be set.
So exactly one of these three parameters must be set.
As mentioned above my example
resource "google_compute_url_map" "default" {
name = "url-map"
default_url_redirect {
https_redirect = true
}
}
works well with the terraform provider built from GoogleCloudPlatform/magic-modules#3379!
Thanks for this clarification (and for the PR) :)
Sorry to bother but is this already available with terraform 0.12.24 and terraform-google-provider 3.19.0? I tried using it the way it was described here with these versions but I keep getting:
Error: Unsupported block type
on lb.tf line 65, in resource "google_compute_url_map" "http":
65: default_url_redirect {
Blocks of type "default_url_redirect" are not expected here.
Thanks in advance!
Got the same issue with versions
Terraform v0.12.24
on load-balancer.tf line 170, in resource "google_compute_url_map" "url_map_http":
170: default_url_redirect {
Blocks of type "default_url_redirect" are not expected here.
The feature was added in v3.20.0 (the CHANGELOG is a good place to go to find out what version a feature was released in!)
I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.
If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!
Most helpful comment
The feature was added in v3.20.0 (the CHANGELOG is a good place to go to find out what version a feature was released in!)