Did you have any redirect issues the other day?

On April 30th, I confirmed that access to https://foo.netlify.com/ was redirected to http://foo.netlify.app/ (foo is a tentative name, but it didn’t depend on the site).

My service relied on site assets on netlify and was getting mixed content errors.
So I rewrote the link from .com to .app and dealt with it.

But now, https://foo.netlify.com/ redirects to https://foo.netlify.app/.
I think this was a problem with netlify.

Any information?


netlify.com subdomains were migrated to netlify.app last year. It’s recommend to use the updated configuration directly.

Yes I know it.
I would like to know why that (was) redirect to http.

What am I missing? You seem to acknowledge that this is the desired and expected behavior.

I think @carrotflakes is asking why it was redirected to the http version as they say in their first line.

To answer that, I don’t think we can comment in it as we ourselves didn’t experience the issue, and don’t know if Netlify actually had that issue in the first place.

Also, you talk about requiring assets from Netlify website to other website and I’m not sure that’s allowed as per the Terms of Service, but I don’t know for sure

OK. I should have asked that day :sweat_smile:

Yes, that’s also a concern. If the usage is not recommended, I’ll consider other way.

Fortunately, there was a log of evidence. Please refer to it if needed:

$ curl -v https://determined-raman-cd2c7b.netlify.com/main.css

  • Trying…
  • Connected to determined-raman-cd2c7b.netlify.com ( port 443 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • successfully set certificate verify locations:
  • CAfile: /etc/ssl/cert.pem
    CApath: none
  • TLSv1.2 (OUT), TLS handshake, Client hello (1):
  • TLSv1.2 (IN), TLS handshake, Server hello (2):
  • TLSv1.2 (IN), TLS handshake, Certificate (11):
  • TLSv1.2 (IN), TLS handshake, Server key exchange (12):
  • TLSv1.2 (IN), TLS handshake, Server finished (14):
  • TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
  • TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
  • TLSv1.2 (OUT), TLS handshake, Finished (20):
  • TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
  • TLSv1.2 (IN), TLS handshake, Finished (20):
  • SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384
  • ALPN, server accepted to use h2
  • Server certificate:
  • subject: C=US; ST=ca; L=San Francisco; O=Netlify, Inc; CN=*.netlify.com
  • start date: Mar 9 00:00:00 2021 GMT
  • expire date: Aug 3 23:59:59 2021 GMT
  • subjectAltName: host “determined-raman-cd2c7b.netlify.com” matched cert’s “*.netlify.com
  • issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
  • SSL certificate verify ok.
  • Using HTTP2, server supports multi-use
  • Connection state changed (HTTP/2 confirmed)
  • Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
  • Using Stream ID: 1 (easy handle 0x7f8bae008200)

GET /main.css HTTP/2
Host: determined-raman-cd2c7b.netlify.com
User-Agent: curl/7.64.1
Accept: /

The logs would definitely help a Support Engineer check if something had gone wrong.

But just to confirm, I am not seeing this issue at present and from your description, it seems like you’re not facing it either. It was just April 30, right? I’m asking so that this can help the engineers narrow down the problem hunt.

1 Like

Yes, there are no issues now. The time is around Fri, 30 Apr 2021 09:49:24 GMT as you can see in the log. I think the problem was continued for about a day.

I would appreciate it if you could investigate, the support team :slight_smile:

Hey there! The .com to .app redirect is typical, however our team did identify a small portion of traffic impacted by a HTTPS > HTTP redirect which should have since been mitigated; do let us know if you observe any recurrence of this.

1 Like

Thank you for your comment!

Just to confirm, HTTPS> HTTP redirects aren’t what you intended, right?

Correct, @carrotflakes – we force all traffic to HTTPS however we did observe an issue with a deploy, which caused some HTTPS traffic to be served over HTTP, which we have since mitigated.