We already have removeHeader(), so why not just stick with that?
On that (rare) occasion that you want to opt-out of the Date header
then "res.removeHeader('Date')". So on any given "res" object there's
an already set "Date" that may be overridden or removed. Seems so
natural so me...
On Mon, Feb 13, 2012 at 12:22 PM, Tim Caswell <[email protected]> wrote:
> 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
