Handle type mismatches in NEL header more gracefully

[dcreager]

Right now the spec says that if you provide the wrong type of value for any of the fields in a NEL policy (e.g., a string for success_fraction), we ignore the entire policy. For fields that have a default value, @igrigorik suggested a more graceful solution would be to use the default value instead.

[yoavweiss]

How will the developer know about their misconfiguration? Seems like 0 entries will be more noticeable than entries with different characteristics

[dcreager]

There isn't a mechanism to send this information back to the server; you'd have to rely on the developer who's trying to add the policy headers to test it out locally. For that, the Chrome implementation has a tab under chrome://net-internals that shows you all of the policies that have been received. I can make sure that shows the policy after parsing (and applying of default values). We can also hook something up in the net log that would print out more detailed error messages about invalid policy headers.

I think that will work regardless of whether or not we go for this more lenient handling of type mismatches.

[nicjansma]

Couldn't this just be a developer tools warning?

Alternatively, via Reporting API, some sort of 'misconfiguration' report?

[clelland]

DevTools makes sense - Chrome at least has an "issues" tab in DevTools now (that would be implementation-specific, I think. I don't think we'd spec it)

I'd be concerned about using the reporting API to report on essentially itself :) It might be too easy for a misconfiguration to result in a huge flood of traffic, possibly directed to the wrong server