If we make the switch on writeHead(200, {date:null}), then it also has
to work if you do setHeader('date', null).But setting a date header of null, or setting a 'sendDate=false' flag on the request both seem fine to me, and are both easy to do compatibly with our future plans. On Mon, Feb 13, 2012 at 11:18, Marco Rogers <[email protected]> wrote: > Err, I'm not sure I agree. We're asking where do we put this option. That's > an api question, not just a let's get this patch out question. Putting it in > writeHead is not only a stop gap, but it encourages people to continue using > writeHead, which we plan to deprecate and discourage. And then we'll still > have to answer this question. So why not answer it now using some > forethought? > > I totally get what you were going for, but it makes no practical sense to > say we shouldn't consider real future roadmap plans. > > :Marco > > > On Monday, February 13, 2012 10:59:41 AM UTC-8, Mikeal Rogers 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
