0

I am building a website using Angular CLI 9.1 using CentOS 7.

I have a domain a.com registered (for PROD environment), and dev.a.com (for DEV environment).

I also had correctly configured the DNS, so a.com points to my production server, and dev.a.com points to my home dev machine.

I had correctly configured the SSL certificates for each domain. None of the online tools I used such as SSL Shoper (and many others) see any problem with my certificates. I am not using the same certificate in both cases, but a different one for each domain. The first certificate will match *.a.com, and the second will match *.dev.a.com.

The DEV environment is correctly configured to accept external connections. For example, I can load the DEV version of the website in my phone after disabling the WIFI and using only 4G connection. And this is true, either using the DEV-DIST version (served by Apache as a regular website, port 80) or the Angular built in server (ng serve, using port 4202)

The Facebook Sharer debugger also gives me the expected results, either with the PROD version or the DEV-DIST version of the website. URLS such as https://a.com/some/other/page and https://dev.a.com/some/other/page, are being successfully crawled by the FB debugger.

The problem with the FB debugger appears when using the built-in Angular server in DEV environment, so https://dev.a.com:4202/some/other/page can't be crawled correctly. I get a URL returned a bad HTTP response code kind of error, with 404 HTTP code. And when I click on See exactly what our scraper sees for your URL, I get:

<!DOCTYPE html>
<html lang="en">
   <head>
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      <meta charset="utf-8">
      <title>Error</title>
   </head>
   <body>
      <pre>Cannot GET /some/other/page</pre>
   </body>
</html>

The 404 code makes no sense to me. As I mentioned earlier, https://dev.a.com:4202/some/other/page works in my phone using a 4G connection, having the WiFi connection disabled.

Even more surprising, crawling https://dev.a.com:4202 seem to work, but only if I adjust the content of the og:url meta-tag to be https://dev.a.com:4202 as well.

The configuration for the Angular built in server is:

...

"serve": {
   "builder": "@angular-devkit/build-angular:dev-server",
   "options": {
      "browserTarget": "frontend:build",
      "port": 4202,
      "host": "0.0.0.0",
      "ssl": true,
      "sslCert": "ssl/fullchain.pem",
      "sslKey": "ssl/privkey.pem",
      "disableHostCheck": true
   },
   "configurations": {
      "production": {
         "browserTarget": "frontend:build:production"
      },
      "dev": {
         "browserTarget": "frontend:build:dev"
      }
   }
}
...

My /etc/hosts file looks like:

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1       localhost localhost.localdomain localhost6 localhost6.localdomain6

127.0.0.1 dev.a.com

So, what I am really asking for is, what would be the reason as to why the FB debugger returns 404 in these specific circumnstances when using the Angular built-in server?

4
  • "when using the built-in Angular server in DEV environment, so https://a.com:4202/some/other/page can't be crawled correctly" - I thought your dev environment was dev.a.com?
    – CBroe
    Commented Jan 23, 2023 at 7:21
  • "crawling https://dev.a.com:4202 seem to work, but only if I adjust the content of the og:url meta-tag to be https://dev.a.com:4202 as well" - you had it pointing to something else before, or just not set at all? og:url must be set to the actual URL you want Facebook to fetch the meta data from.
    – CBroe
    Commented Jan 23, 2023 at 7:22
  • @CBroe, apologies for the mistake. I had it corrected. Thanks
    – Nicolas
    Commented Jan 23, 2023 at 9:40
  • @CBroe, the og:url was pointing to https://dev.a.com:4202/some/other/page. In PROD environment would have been pointing to https://a.com/some/other/page. The only way that the crawler wouldn't give me an error in DEV was to change og:url to https://dev.a.com:4202, and to make it crawl that same URL, but that is not what I wanted to achieve.
    – Nicolas
    Commented Jan 23, 2023 at 9:43

0

Browse other questions tagged or ask your own question.