Error with domain without "www"

[MattGom]

What information was incorrect, unhelpful, or incomplete?

I test my website : lafrenchtech.gouv.fr
And I got the answer : "Error: The site seems to be down."
So, I test lafrenchtech.gouv.fr/ and I got the answer : "Error: www.lafrenchtech.gouv.fr/ cannot be resolved"

What did you expect to see?

I expected to see the analysis of lafrenchtech.gouv.fr, which works perfectly BUT does not has any subdomain "www".

It appears that HTTP Observatory seeks only the "www" subdomain, and add it to the name of the website.
In 2025, this behaviour is not very relevant. It should test exactly the name entered.

Do you have any supporting links, references, or citations?

No response

Do you have anything more you want to share?

Thanks a lot for this very helpful tool which make it possible to enhance every website we build !

[argl]

Thanks for reporting, I will look into it.

[argl]

There seems to be a problem with the headers the site is sending. Nodejs does not like them for some reason. I can reproduce the failure with this:

$> node
Welcome to Node.js v20.18.1.
Type ".help" for more information.
> await fetch("https://lafrenchtech.gouv.fr/")
Uncaught TypeError: fetch failed
    at node:internal/deps/undici/undici:13392:13
    at async REPL1:1:33 {
  [cause]: HTTPParserError: Response does not match the HTTP/1.1 protocol (Invalid header value char)
      at Parser.execute (node:internal/deps/undici/undici:5942:19)
      at Parser.readMore (node:internal/deps/undici/undici:5901:16)
      at TLSSocket.<anonymous> (node:internal/deps/undici/undici:6229:18)
      at TLSSocket.emit (node:events:518:28)
      at TLSSocket.emit (node:domain:552:15)
      at emitReadable_ (node:internal/streams/readable:834:12)
      at process.processTicksAndRejections (node:internal/process/task_queues:81:21) {
    code: 'HPE_INVALID_HEADER_TOKEN',
    data: '\n' +
      '                child-src https: platform.twitter.com; img-src https: data:;\n' +
      '                font-src https: data:;\n' +
      "                style-src  https: 'unsafe-inline' 'unsafe-eval' 'self';\n" +
      "\t\tscript-src https: 'unsafe-inline' 'unsafe-eval' 'self';\r\n" +
      'Referrer-Policy: origin\r\n' +
      'X-Content-Type-Options: nosniff\r\n' +
      'X-Frame-Options: SAMEORIGIN\r\n' +
      'Strict-Transport-Security: max-age=31536000; includeSubDomains; preload\r\n' +
      '\r\n'
  }
}

Looking ath the raw header data, the CSP one does not seem to be right, it contains line breaks in the value:

Content-Security-Policy: default-src https: 'self'; object-src 'none';
                child-src https: platform.twitter.com; img-src https: data:;
                font-src https: data:;
                style-src  https: 'unsafe-inline' 'unsafe-eval' 'self';
                script-src https: 'unsafe-inline' 'unsafe-eval' 'self';

It should be a single line.

Browsers obvously do not trip over this, but node (on which obseravtory is built) is more strict. In fact "line folding" in header values was allowed in times past, but it is now explicitely forbidden:

Historically, HTTP header field values could be extended over
multiple lines by preceding each extra line with at least one space
or horizontal tab (obs-fold). This specification deprecates such
line folding except within the message/http media type
(Section 8.3.1). A sender MUST NOT generate a message that includes
line folding (i.e., that has any field-value that contains a match to
the obs-fold rule) unless the message is intended for packaging
within the message/http media type.

I would strongly encourage sending the CSP header as a single line, then Observatory can do its work.

Thank you for reporting, I was not aware of this mismatch between browser's and node's HTTP implementation!