2

I have a number of domains hosted on one server. I tried them as sub-domains but that was a failure. So I obtained new certificates and I have them configured as Add-On_Domains.

They are all using the same template for .htaccess and are configured identically in cpanel. They are all working, except for .app

I know that Google owns this TLD and it has to be secure. But not all combinations are working. These are not working

https://www.example.app/
http://www.example.app/

They give "COMMON_NAME_INVALID" or similar. But these work

https://example.app/
http://example.app/

This is my complete .htaccess file

RewriteEngine On

RewriteCond %{HTTPS} =on
RewriteCond %{HTTP_HOST} ^www\.example\.app$ [NC]
RewriteRule ^(.*)$ https://example.app/$1 [R=301,L]

RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP_HOST} ^(www\.)?example\.app$ [NC]
RewriteRule ^(.*)$ https://example.app%{REQUEST_URI} [R=301,L,QSA]

# stop it being rooted from .software
RewriteCond %{HTTP_HOST} !^example\.app$ [NC]
RewriteRule ^ - [F]

#Force hmtl extn
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}\.html -f
RewriteRule ^(.*)$ $1.html

Header always set Content-Security-Policy "upgrade-insecure-requests;"
Header append X-Frame-Options: "SAMEORIGIN"
Header append X-Content-Type-Options: "nosniff"

# 1 month
<filesMatch ".(ico|jpg|jpeg|png|gif|mp4|avi|mov|svg)$">
 Header set Cache-Control "max-age=2592000, must-revalidate"
</filesMatch>
# 2 days
<filesMatch ".(js)$">
 Header set Cache-Control "max-age=172800, must-revalidate"
</filesMatch>
# 5 mins
<filesMatch ".(css|html|shtml)$">
 Header set Cache-Control "max-age=120, must-revalidate"
</filesMatch>
# never
<filesMatch ".(rar|zip)$">
 Header set Cache-Control "no-cache, must-revalidate"
</filesMatch>

# compress css and javascript for now
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/opentype

<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_include mime ^text/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_include handler ^cgi-script$
</ifModule>

Have I got a typo or is there something else going on ?

https://www.example.app has this trace

Request URL: https://www.example.app/
Referrer Policy: strict-origin-when-cross-origin

Request Headers
Provisional headers are shown
 sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="97", "Chromium";v="97"
sec-ch-ua-mobile: ?1
sec-ch-ua-platform: "Android"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Mobile Safari/537.36

http://www.example.app has this trace

Request URL: http://www.example.app/
Request Method: GET
Status Code: 307 Internal Redirect
Referrer Policy: strict-origin-when-cross-origin

Response Headers
Location: https://www.example.app/
Non-Authoritative-Reason: HSTS

Request Headers
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Mobile Safari/537.36

The above is from Chrome. When Googling it would appear that Chrome is enforcing something for .app domain. However, it doesn't work on Firefox either. And where is the 307 coming from ?

3
  • There is nothing specific about .app names... except that Google added the TLD to the HSTS preloading list which means you need a valid certificate for any name you use under this TLD. Jan 27 at 8:58
  • Also see searchenginejournal.com/… Jan 27 at 10:51
  • @PatrickMevzek I am none the wiser. Because there is an issue. Either of my own making or a side-effect of the 307. Its almost as if the 301 does not work on it. Or you are not allowed to strip out the www. It would be nice to hear from someone who has tried to use an .app Jan 27 at 12:14

1 Answer 1

3

You've basically answered your own question...

I know that Google owns this TLD and it has to be secure.

They give "COMMON_NAME_INVALID" or similar

That's an SSL cert error (in the browser) - nothing to do with .htaccess. The request is not "successfully" reaching your server. .htaccess is not even processed.

Your SSL cert does not appear to cover the www subdomain.

Chrome is enforcing something for .app domain.

Yes, that's why it "has to be secure", it's enforcing HTTPS in the browser before it even sends the request to your server. If the server does not respond correctly on HTTPS then the connection is blocked by the browser.

This is what HSTS preloading is all about. The .app TLD (as well as many other Google TLDs) are included in the HSTS preload list that is compiled into Chrome (and other mainstream browsers).

307 Internal Redirect

It's "internal" to the browser. It's not a conventional (external) redirect. This is really just how Chrome is reporting it. 307s preserve the request method. (But why a 307 "temporary" and not a 308 "permanent"? An HSTS upgrade is effectively permanent.)

Reference:

5
  • Are you saying that I need two certificates, with and without www ? I will read those links tomorrow morning. Jan 27 at 12:16
  • 2
    You don't need two certificates. You can use one certificate that covers both example.com and www.example.com. Such a certificate is known as "subject alternative name" or SAN. You will need to get your certificate reissued by tomorrow morning if you want the www to work by then. Jan 27 at 12:31
  • To me its another certificate. I already got a main +5 SAN, but they got used up. Its a pity that people in the industry dont understand it. I have been telling the SSL certificate providers and my web hosters for months. That there is something different about the .app that they do not understand. And they keep telling me to flush my browser caches. :-) Jan 27 at 22:15
  • @MrWhite, To be sure, I just checked after removing my redirections in the .htaccess. They definitely have no effect. Maybe, for future visitors you may want to emphasize in your answer that the modern browsers are ignoring redirections on the .app urls. But I think I will leave them in for older browsers.👍 Jan 28 at 0:01
  • @RohitGupta It's wrong to say that "modern browsers are ignoring redirections on the .app URLs". It's because you don't have a valid SSL cert on the www subdomain of the .app domain that the request is not reaching the server - so the redirects are not processed. Install an SSL cert on the www subdomain and the redirects will be processed. The same applies to any domain if you directly request HTTPS. That's all the browser is doing... it's upgrading the request from HTTP to HTTPS automatically.
    – MrWhite
    Jan 29 at 1:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.