Yes, we could also just only send the date header if it's not already been set to some value, where `null` or `undefined` values are skipped over.
Just make sure we don't send `date: undefined` or `date: null` in that case :) On Mon, Feb 13, 2012 at 10:59, Mikeal Rogers <[email protected]> wrote: > we can cross that bridge when we come to it. > > IMO, patches against master should be made against master without regard for > future plans for re-writes. It's the job of the re-writer to make all the > tests pass so if your change goes in with a test it'll still work after the > re-write. > > -Mikeal > > On Feb 13, 2012, at February 13, 201210:49 AM, Marco Rogers wrote: > >> Well there's a separate plan being discussed right now to upgrade the API to >> ServerResponse anyway. writeHead is going to be deprecated, so that's not >> the best place to put it. But I do agree we should minimize unnecessary >> properties on res. It would be nice to have a pseudo standard way of >> specifying options across node. I haven't put any thought into it yet. But >> one thing I like is just using an options hash. It's not just for functions >> you know :) >> >> res.options.shouldSendDate = true. >> >> This way we can add whatever we want and the chance of collision is >> minimized. Of course options is a fairly common name. That's why it might be >> a good idea to come up with some kind of convention. People know enough not >> to name a function "on" or close" these days. >> >> :Marco >
