Why not just set the date header to null? Seems more intuitive to me.
Am 13.02.2012 02:55 schrieb "Mark Nottingham" :
I've updated my patch. It already has an undocumented way to disable; e.g.,
var server = http.createServer(function(req, res) {
res.shouldSendDate = false;
res.writeHead(200,
Issac said:
> 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.
... and there's already a flag in the patch.
I'm going to update the name to "sendDate", add some documentation a
On Mon, Feb 13, 2012 at 8:53 PM, Nathan Rajlich wrote:
> 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
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
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
s
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, 20
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'
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 wrote:
> we can cross tha
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 F
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
spe
On Feb 13, 2:55 am, Mark Nottingham wrote:
> I've updated my patch. It already has an undocumented way to disable; e.g.,
>
> var server = http.createServer(function(req, res) {
> res.shouldSendDate = false;
> res.writeHead(200, {
> 'Content-Type' : 'text/plain',
> });
> res.end("foo!")
This API lgtm, but it *should* be documented.
On Sun, Feb 12, 2012 at 17:55, Mark Nottingham wrote:
> I've updated my patch. It already has an undocumented way to disable; e.g.,
>
> var server = http.createServer(function(req, res) {
> res.shouldSendDate = false;
> res.writeHead(200, {
>
I've updated my patch. It already has an undocumented way to disable; e.g.,
var server = http.createServer(function(req, res) {
res.shouldSendDate = false;
res.writeHead(200, {
'Content-Type' : 'text/plain',
});
res.end("foo!");
});
Is that adequate? It's similar to the undocumented h
Ok, who's gonna write up a patch. Mark, you did it well the first time :)
Just add a way to disable it, and we can land this on master.
On Thu, Feb 9, 2012 at 10:57, Mikeal Rogers wrote:
> Again, this is the *exact* conversation we had about the Host header, down to
> the "but i need to remove
Again, this is the *exact* conversation we had about the Host header, down to
the "but i need to remove it for testing". Turned out you really do, because
people's shitty HTTP implementations won't give you the right headers and
you'll need to test that you have sane defaults.
If we can't learn
I'm not against a flag to turn it off, but I'm not sure it's really
necessary. The patch allows you to create the Date yourself (i.e., it won't
replace or dup it), so the user does have control.
The only use case that isn't met is the ability to send a response without
a Date. I don't really bu
http-nanny sounds like an @substack module.
On Wednesday, February 8, 2012 12:24:29 PM UTC-8, Dean Landolt wrote:
>
>
>
> On Wed, Feb 8, 2012 at 3:24 PM, Mikeal Rogers wrote:
>
>> This is the exact same conversation we had over the host header.
>>
>> Unfortunately the host header went in at first
On Wed, Feb 8, 2012 at 3:24 PM, Mikeal Rogers wrote:
> This is the exact same conversation we had over the host header.
>
> Unfortunately the host header went in at first without a way to disable
> it. Now there is, we should replicate that.
>
Yes. That. Something like what Tim Caswell suggested
This is the exact same conversation we had over the host header.
Unfortunately the host header went in at first without a way to disable it. Now
there is, we should replicate that.
-Mikeal
On Feb 8, 2012, at February 8, 20121:48 PM, Marco Rogers wrote:
> +1 to this going in. Node boasts a lot
+1 to this going in. Node boasts a lot about getting http right. This seems
like a glaring omission when viewed through that lens. I totally agree that
there should be an easy way to opt out. But I hope people aren't objecting
due to "performance" concerns. The pull request linked above has gone
For what it's worth, here is what I did in Luvit and it's worked well so far.
There are several automatic headers. I understand that sometimes
people don't want the magic headers and so I put in a trivial switch
to disable any of them:
https://github.com/luvit/luvit/blob/master/lib/http.lua#L110-1
This is going to make http-signing unpredictable and harder to code. You
can sign whatever you want but signing date is a default practice.
I would rather have control over the header.
I say leave it to userland to add the header if it's really necessary.
It's a waste of bandwidth to add Date headers when they're not needed.
On Tue, Feb 7, 2012 at 1:30 PM, Isaac Schlueter wrote:
> I don't know... I kind of see this as somewhat similar to defaulting
> to sending the Host header on requests.
>
> As long as there's some way to opt out of it, the default should make
> node servers behave the right way. Maybe you can set
+1 for this as well, if people want faster hello world benchmarks they
can monkey-patch or something haha
On Feb 7, 6:12 pm, Mikeal Rogers wrote:
> This should go in.
>
> I mean, I care about this kind of stuff, I don't like breaking the spec, but
> I don't think any of my server code uses a Dat
I don't know... I kind of see this as somewhat similar to defaulting
to sending the Host header on requests.
As long as there's some way to opt out of it, the default should make
node servers behave the right way. Maybe you can set the date header
to null if you want to not send the date?
> It's
On Tue, Feb 7, 2012 at 2:57 PM, Matt wrote:
> On Tue, Feb 7, 2012 at 2:54 PM, Ben Noordhuis wrote:
>
>> On Tue, Feb 7, 2012 at 18:47, Martin Cooper wrote:
>> > On Mon, Jan 30, 2012 at 8:34 PM, Martin Cooper
>> wrote:
>> >> As mnot pointed out in pull request #311 (back in Sep 2010), date
>> >>
I guess the question is "is there ever a case where you wouldn't want
a date header?" If there is a valid case for this, then I see no
reason for node not to add this in.
On Tue, Feb 7, 2012 at 1:54 PM, Ben Noordhuis wrote:
> On Tue, Feb 7, 2012 at 18:47, Martin Cooper wrote:
>> On Mon, Jan 30,
On Tue, Feb 7, 2012 at 2:54 PM, Ben Noordhuis wrote:
> On Tue, Feb 7, 2012 at 18:47, Martin Cooper wrote:
> > On Mon, Jan 30, 2012 at 8:34 PM, Martin Cooper
> wrote:
> >> As mnot pointed out in pull request #311 (back in Sep 2010), date
> >> headers are required in responses. The pull request a
On Tue, Feb 7, 2012 at 18:47, Martin Cooper wrote:
> On Mon, Jan 30, 2012 at 8:34 PM, Martin Cooper wrote:
>> As mnot pointed out in pull request #311 (back in Sep 2010), date
>> headers are required in responses. The pull request addressed that,
>> and it looked like it was merged in. But if it
Anyone? It seems to me that this is important functionality that's
currently missing from Node (and is entirely appropriate for core).
--
Martin Cooper
On Mon, Jan 30, 2012 at 8:34 PM, Martin Cooper wrote:
> As mnot pointed out in pull request #311 (back in Sep 2010), date
> headers are require
32 matches
Mail list logo
