So what's wrong with the approach I used in luvit. There is an
explicit place to enable, disable, and configure the automagic
headers. Having headers with null values being the way to disable
something seems really confusing.
Just say `res.autoDate = false` or `res.setAuto('header', false)` or
something like that. I find having the default settings in the
prototype to be a clean and effecient way to do it. If you want to
disable or configure something globally, change it in the prototype.
If you want to change it at the request level, override it in the
instance (which inherits from the prototype).
I haven't dug into node's code for this in a while (since I drafted
the first mutable headers patch), and from what I remember it's fairly
complicated because of the way node evolved, but I still think this
can be done cleanly and clearly without too much effort.
On Mon, Feb 13, 2012 at 2:08 PM, Isaac Schlueter <[email protected]> wrote:
> 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
