Feature poll: Do you use the clientError event?

[Isaac Schlueter]

Do you use the clientError event?

Please choose one:

1. Yes, I use it all the time. Please don't change it ever, thank you.

2. I don't use it, but I'm aware of it, and I think I might someday.

3. I don't use it, and I think it's stupid.

4. The what now event?


Thanks.

[Roly Fentanes]

4

[Mark Hahn]

http://nodejs.org/api/http.html#http_event_clienterror

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Mark Hahn]

3

[mscdex]

On Aug 29, 7:07 pm, Isaac Schlueter <i...@izs.me> wrote:
> Do you use the clientError event?
>
> Please choose one:

2.5 (I don't use it, but I'm aware of it, and I'm not sure yet if I'll
use it some day.)

[Mark Hahn]

What happens if there is a client error and you aren't listening for it?  Do you get a close or something?

[Dan Shaw]

:) 2.5 too: I don't use it, but I'm aware of it, and I'm not sure if

I'll use it some day.

Daniel Shaw
@dshaw

[Marco Rogers]

2.5. Never used it.

:Marco

On Wednesday, August 29, 2012 4:07:23 PM UTC-7, Isaac Schlueter wrote:

[Shigeki Ohtsu]

clientError on http.Server 2.5(I've never used before)
clientError on https.Server 2(I sometimes used for debug)

I think that clientError on https.Server is valuable to check SSL errors as

$node https_server2.js
ssl server listening on 8443
clientError: TLS session renegotiation attack detected.
clientError: TLS session renegotiation attack detected.
clientError: 3077781248:error:140760FC:SSL
routines:SSL23_GET_CLIENT_HELLO:unknown
protocol:../deps/openssl/openssl/ssl/s23_srvr.c:589:

refs.

http://nodejs.org/api/tls.html#tls_client_initiated_renegotiation_attack_mitigation

[Tim Caswell]

4

[Christian Taltas]

4

--

Christian Taltas, Cofounder and CTO
chri...@yupana.com | +1 415 562 6013
Yupana Systems, Inc.
yupana.com | +1 650 399 0000 ext. 102

[Christian Tellnes]

2.5

--
Mvh. Christian Vaagland Tellnes
http://christian.tellnes.com/

[jg]

2

[dhruvbird]

4 - didn't know it existed.

[dhruvbird]

So is this like a place where _every_ accepted connection's error is propagated (in case there is an error on the accepted connection)?

Also, what are the semantics? I mean does the error get propagated irrespective of the fact that it might be handled as an 'error' event on the specific 'req' (readablestream) object?

[Ben Noordhuis]

Yes and yes.

[Bradley Meck]

3

Hook into .on('request') or .on('connection') if you want it, thats how i do it already.

[Eldar]

4

[dhruvbird]

Plus, it would be interesting to know the motivation behind this use case and what scenario it was envisioned for. One thing that comes to mind is efficiency since every request will not have to have a handle to a function. However, apart from the most trivial of use-cases, do you think that passing a handle to the request (and/or) response objects would make this handler generally more useful?

[Mariusz Nowak]

4

[Luke Arduini]

2.5