Setting a deprecated header should not break

The current behavior prevent from simply replacing https by http2 in existing peace of software

It should not throw a breaking exception. Instead It should:

• log a deprecation warning
• either set the header anyway (if setting it has no impact), or drop it (if it is no longer meaningful) or migrate it if it is replaced by new header(s).

But in all cases, the request should be processed

[pavel]

@nwgh

I’m not so sure - there’s no better way to get someone to fix their code than by throwing a breaking exception!

I disagree, because someone might be a 3rd party HTTP/1 server, for example, CouchDB, which uses only HTTP/1. You’re forgetting that node-http2 can and will be used as a proxy and for now mostly as HTTP/2 to HTTP/1. This should be focused around actual usage and not “programming best practices”. You can add strict mode for those who want to be as close to spec as possible.

[pavel]

@DaSchTour You can use node-spdy instead as it does handle such cases. (I assume that the reader understands that this advice is not advertisement of node-spdy, and just a library to workaround the issue. No comparison should be implied from my comment).

BrowserSync usage example:

// First run: npm install browser-sync spdy
const bs = require('browser-sync').create();

bs.init({
    server: './app',
    httpModule: 'spdy',
    https: true
});