The current level of abstraction is unnecessary.

Currently, Managed VM deploys take about 5 minutes, even though the server code is only a few dozen files and can built and run (via go run) in a few seconds.
I can sometimes do other work during a deploy, but often I just have to twiddle my thumbs before I can check if the deploy worked.

Given how slow that is, it might literally be more cost-effective to buy a domain and run on a VM.

From chromium/hstspreload#3

I had an error in my HSTS header but hstspreload.appspot.com didn't alert me to this error because my site was already in the preload list.

Hi all. I can't figure out how to fix my .htaccess file to not throw up an error — namely, 'Error: HTTP redirects to www first.'

http://acmewidgets.com (HTTP) should immediately redirect to https://acmewidgets.com (HTTPS) before adding the www subdomain. Right now, the first redirect is to https://www.acmewidgets.com/.

My .htaccess file is as follows. Can anyone tell me what I'm doing wrong? I've experimented but it just ends up breaking my redirect. 😢

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS

RewriteCond %{HTTP_HOST} ^acmewidgets.com [NC]
RewriteRule ^(.*)$ https://www.acmewidgets.com/$1 [L,R=301]

From chromium/hstspreload#53
See https://github.com/chromium/hstspreload.appspot.com/tree/server-hsts for the latest attempt.

The history looks green because I rerun them manually, but the test fail about half the time because the local datastore emulator setup fails.

googleapis/google-cloud-go#224 would really help here, but maybe I can work around it.

The second requirement says: "Redirect from HTTP to HTTPS on the same host." I'd like to suggest changing it to "redirect from HTTP to HTTPS on the same host, or don't allow connections to port 80". The reason is that some servers may want to completely block plaintext HTTP if the domain is not visited by users directly (such as image, JavaScript hosting domains).

Perhaps also remove or restrict local API keys to prevent playing with prod data locally?

e.g. https://hstspreload.appspot.com/#removal

People can't follow directions.

I've experimented both with Javascript and server-side templating.

Due to the large potential in variation for how long it takes to check a domain (latency to server, 10s timeouts for certain checks depending on server configuration), it is much better to show a spinner than to block a page load. I don't want to do any tricks that render the static content with some parts delayed, so the best solution is to go all-in on Javascript.

Given that the current site uses Javascript, I don't think this will be a problem.

From chromium/hstspreload#49

When submitting a site, loader keeps spinning for minutes and minutes. SSL checking can be slow, I know (Qualys SSL Labs), but this ends up doing nothing.

Here is an example: http://wmfusercontent.org redirects to https://wmfusercontent.org, which then redirects to https://www.wikimedia.org. https://wmfusercontent.org sets the HSTS header with includeSubDomain and preload, which I believe satisfy all requirements for preloading, although https://www.wikimedia.org doesn't set includeSubDomain directive. But the error message says:

HTTP redirects to a page without HSTS
http://wmfusercontent.org redirects to https://wmfusercontent.org/, which does not serve a HSTS header that satisfies preload conditions. First error: No includeSubDomains directive

Could you please clarify the requirements or is the error message wrong? Thanks!

If I do a query for gist.github.com, it will say that it's not preloaded, even though the parent domain (github.com) is preloaded.

This is a bit confusing because the HTTP Observatory says that it's pinned (which it is, because includeSubDomains is set with preload), but the hstspreload results say that it isn't.

Also, I have just some general curmudgeonly issues about the response being "Yes" or "No", instead of a boolean. That said, a great option would be "Yes", "No", and "viaParentDomain" or something like that.

"ProdBackend represent the production"

Motivated by #35.

Ideally, everyone would use transport_security_state_static.json as the source of truth. However, a raw download from git requires reading base 64 and stripping // comments (taking into account that there are URl strings containing //) just to get to the JSON content. And if everyone does it, it's an unnecessary load on the git server.

Anyone using Go can use preloadlist.NewFromLatest(), but not everyone uses Go.

Proposal: tell devs to use a future-proof URL like https://hstspreload.appspot.com/v2/status?domain=example.com
If we version properly, we can still change the API if needed (and send 404 Not Found or 410 Gone for old versions).

I'd like to add the site https://neběží.xyz (https://xn--neb-tma3u8u.xyz) to the HSTS preload list. This site is intentionally accessible only over IPv6.

When I submit the preload request via https://hstspreload.appspot.com/?domain=neb%C4%9B%C5%BE%C3%AD.xyz I get this error response:

Error: Cannot connect using TLS
We cannot connect to https://xn--neb-tma3u8u.xyz using TLS ("Get https://xn--neb-tma3u8u.xyz: dial tcp [2001:1528:132:70::ebe2]:443: connect: network is unreachable").

Run once:

> curl localhost:8080/update

Run again, and PutStates tries to write:

> curl localhost:8080/update
The preload list has 11360 entries.
- # of preloaded HSTS entries: 11101
- # to be added in this update: 1
- # to be removed this update: 0
[]string{"zzw.ca"}
Updating 1 entries... done.
Success. 1 domain states updated.

e.g. allow hyperlinks to be marked up semantically (rather than e.g. using regexes in the frontend).

This requires support from hstspreload.Issue.

In particular, we should make it very easy to do safe redirects.

https://mozilla.github.io/server-side-tls/ssl-config-generator/ isn't quite right for this, since it is meant for the HTTPS part, not the redirects.

"Internal error: not convert domain to ASCII"

For https://crbug.com/608599

There is a local datastore emulator, but I haven't figured out how to set it up yet.

With the error message...

`http://example.com` (HTTP) should immediately redirect to
`https://example.com` (HTTPS) before adding the www subdomain. 
Right now, the first redirect is to `https://www.example.com/`.

May I ask why this needs to be the case?

The website I have in mind uses the www subdomain to give a cookie-less subdomain, and to potentially allow us to use a CDN in future (typically they use a CNAME DNS entry).

So I've setup a redirect, and from a performance point of view, I want to avoid doing two 301 redirects.

From @dylmye at #44 (comment)

I'm pretty sure I know what's going on: the scheme is stripped by some of the code, but inconsistently.

e.g. in case the port is taken.

"status" doesn't mean the same as PreloadStatus

By convention, functions starting with Test should be used only for testing.