Global cors and security options not respected in 404

[erfanio]

What are you trying to achieve or the steps to reproduce?

From API docs:

If set to 'ignore', any incoming Origin header is ignored (present or not) and the 'Access-Control-Allow-Origin' header is set to '*'

I have this in my hapi server configs:

...
    routes: {
      cors: { origin: 'ignore' },
...

This works fine most of the time

But when a route doesn't exist, the 404 response doesn't include the cors headers.

What did you expect?

I expect to have access-control-allow-origin: * on the 404

Context

• node version: 10
• hapi version: 17.4
• os: Linux

[vladikoff]

I was about to file this bug, but saw yours.

This can be reproduced with this:

git clone https://github.com/vladikoff/issue-hapi-17-404-headers.git
cd issue-hapi-17-404-headers
node index.js

Navigate to http://localhost:3000

Existing route:

404 route: http://localhost:3000/404something

Response headers are missing security route options:

This seems like a regression in Hapi 17. In hapi 16 this worked fine, we have testa covering this behaviour.

[vladikoff]

Sample code:

'use strict';

const Hapi = require('hapi');

const server = Hapi.server({
  port: 3000,
  host: 'localhost',
  routes: {
    cors: true,
    payload: {
      maxBytes: 16384
    },
    security: {
      hsts: {
        maxAge: 15552000,
        includeSubdomains: true
      },
      xframe: true,
      xss: true,
      noOpen: false,
      noSniff: true
    },
  }
});

server.route({
  method: 'GET',
  path: '/',
  handler: (request, h) => {

    return 'Hello, world!';
  }
});

server.route({
  method: 'GET',
  path: '/hello',
  handler: (request, h) => {

    return 'Hello, ' + encodeURIComponent(request.params.name) + '!';
  }
});

const init = async () => {

  await server.start();
  console.log(`Server running at: ${server.info.uri}`);
};

process.on('unhandledRejection', (err) => {

  console.log(err);
  process.exit(1);
});

init();

[vladikoff]

Workaround mentioned here: #3658 (comment)

[bmgdev]

@vladikoff have you seen any official fix for adding a global cors: true? I'm bewildered how its been this long without a fix. This seems like a giant use case/issue for most people.

[hueniverse]

This is actually two separate issues. v17 broke the security headers on 404 responses. CORS header never worked on v16 either. I am trying to decide if 404 should honor CORS headers settings and if it should, if this is a bug fix or a breaking change...

@nlf @kanongil thoughts?

[bmgdev]

complete oversight, but i was able to add this to my manifest. had no idea, so simple.

[kanongil]

Hmm, tricky. The docs, could both mean every defined route, or every route (including built-in). I would probably expect it to just apply to all responses (contrary to the current implementation).

Adding CORS headers to unrouted 404 responses will add a bit of extra processing, and some extra bytes to the responses. There is also a remote possibility that it can trigger a bug in a browser app, due to receiving the actual 404 response instead of a CORS fail.

For reference:

server.options.routes

Default value: none.

A route options object used as the default configuration for every route.

[hueniverse]

due to receiving the actual 404 response instead of a CORS fail

It will not change the 404 response, just add a few headers as configured for the other routes.