### url: return valid file: urls from url.format() [#7234](https://github.com/nodejs/node/pull/7234)
@trott: semver-major change, needs approval from CTC.
Real fix will be @jasnell’s HTTP compliance work.
In browsers `file:/home/joshgav/myfile.txt` is auto-corrected to `file:///home/joshgav/myfile.txt` (i.e. slashes are prepended to the path and hostname is an empty string). This change institutes the same in Node.js.
Are there other protocols which require additional slashes (`//`) if hostname isn’t specified? Yes, but hard to heuristically determine if needed.
### http: don't inherit from Object.prototype [#6102](https://github.com/nodejs/node/pull/6102)
Replace headers object ({}) in req/res with StorageObject, which doesn’t delegate to Object.prototype. But this will break anyone using regular `Object` methods on header props.
@trevnorris: Why don’t we intercept calls to properties with checks to an internal dictionary of actual headers? If the key isn’t there, then try to call Object.prototype.
How would that effect perf?
It’s the right decision because otherwise can’t use headers with certain names like `__proto__`.
Better to do a deprecation cycle. How? Insert something (proxy) between actual call to property, would issue deprecation warning first. This would be temporary, eventually this interceptor/proxy would go away.
Need to disambiguate ES6 modules and regular scripts (which include CJS modules). Cannot determine if file is module, script, etc. from code itself. For this reason Node decided to use `.mjs` extension for ES6 modules.
New proposal: If `import` or `export` keywords are in module code, then use module goal. So no need for extra metadata or file extension. But would have to parse file to check for presence of these keywords.
This would be part of ECMA262 so browsers would do the same, but needs to be ironed out in TC39. On [agenda][TC39 Agenda] for 7/26 TC39 meeting.
What if nothing is imported or exported? Could do `export default null` to export nothing.
Starting off, preferred goal when preparing code would be CommonJS/script, later on could change to ES6/module.
Caching is more feasible.
Provides more seamless flow from CJS to ES6 in the future.
Will packaging tools need to implement parsing logic too to package properly? Yes, but there are possibilities listed in the repo.
What other differences between scripts and modules?
-`await` keyword only in modules according to ECMA262
-`modules.root` in package.json is intended to allow mirrored directory structure for use with ES6; but technically all it does is redirect file system calls and it could be used for other purposes, so it’s not reliable.
Purpose of modules.root - allows redirection within a module, e.g. `module/file.js` doesn’t necessarily resolve to `./file.js` within the directory, could be redirected to `${module.root}/file.js`. This allows side-by-side CJS and ES6 among other things.
What about for human reading? How can people differentiate at a glance between CJS and ES6?
-`import`’s are generally at the top, `export`s at the bottom. If you see `import` it’s an ES6 module.
How are browsers dealing with this? Older browsers which encounter `<script type=”module”>` and don’t recognize the type will skip it. Loading is asynchronous by default.
Are browsers concerned about transition period from CJS to ES6? How do they load older scripts, e.g. jQuery?
**Should Node move this forward as alternative to `.mjs` proposal?**
TBD. What does TC39 think of this? It’s on agenda for next F2F (see above).
