broken pipe issue with runserver #4444
Ido Sebastiaan van Oostveen
While writing a little patch to get rid of the (annoyingly loud) 'broken
pipe' exception/traceback; i found that there actually a ticket for it
#4444 which is marked won't fix.
I would like to throw in two options for making this error a little less
noisy. (As this error is 'common browser error' which browsers closing
the connection while the dev server is still sending data) Replacing it
with something more explicit as suggested by PhiR before setting the
ticket wontfix.
With the patches i've uploaded on #4444 the '43, broken pipe' now looks
like this:
[31/May/2008 20:47:21] "GET /favicon.ico HTTP/1.1" 200 6335 Broken pipe
My $0.02 cents...
Ido
Ludvig Ericson
While writing a little patch to get rid of the (annoyingly loud) 'broken
pipe' exception/traceback; i found that there actually a ticket for it
#4444 which is marked won't fix.
Ido Sebastiaan van Oostveen
thats why i called it an 'issue' between quotes :)
It's probably better called something like a style issue.
But some people see this as an problem, cause you get a loud (perhaps
for some scarry) looking exception. For something which is essentially a
non-problem.
I'm all for not fixing every little quirck browsers throw at us, but
this could be a very very simple patch which will stop the console being
littered with useless exceptions when using runserver.
It just feels wrong IMHO to have exceptions raised for users where the
reaction too questions about it will be: 'just ignore it completely,
it's a browser issue'.
- Ido
Graham King
something serious is broken.
Ludvig Ericson
Hash: SHA1
> I'm +1 on this. An exception should only appear on the console if
> something serious is broken.
The term you're looking for is "error", not exception. An exception
can be expected.
Where would you fellows suggest we catch this exception, and do
nothing? Because that's half of the problem: there's no suitable place
for it. From the HTTP-to&from-WSGI layer seen, a broken pipe is
serious business. From the view's view (tee-hee), it won't ever
matter. From the users' view, it all depends.
I'd also like to duly note that these broken pipes can be errors - a
misbehaving browser, perchance. Or maybe even Python's socketing gone
wrong!
I'd rather see this be leaved as-is, since I haven't seen a single
report on these broken pipe 'issues'.
Ludvig "toxik" Ericson
ludvig....@gmail.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkhDQpMACgkQXnZ94Kd6KafmLQCggNZcpjucwTL/vHztq44AqgDa
SqkAn2+S17lvVQ4NxLqienrNtQKNh8sw
=k3vX
-----END PGP SIGNATURE-----
Emil Stenström
I'd rather see this be leaved as-is, since I haven't seen a singlereport on these broken pipe 'issues'.
I'm using PhantomJS (headless webkit browser) to test for javascript errors on my site. Using the LiveServerTestCase it's possible to spawn a test server, and using Python's subprocess I can call PhantomJS to access that server and assert that there are no errors.
Problem is, the test server is spitting back broken pipe errors. By reading explanations elsewhere I've understood that this is a browser problem, that they are not supposed to break connections like that, but the fact is that they are. It feels strange to read recommendations that I should just ignore the errors, since having random stacktrace printouts in my tests feels extremely sloppy.
Given that browsers behave like they do, and we're not able to change that, I suggest that ticket #4444 is reconsidered, and no marked as wontfix.
As a workaround I would have hoped for a way to ignore the messages in some other way. I've tried setting up logging to ignore the errors, but failed. My guess is that these errors don't go through the logger. Maybe this couple me the recommended (and documented) way of handling this?
(Here's the code if you want to reproduce: http://stackoverflow.com/questions/13287490/is-there-a-way-to-use-phantomjs-in-python/13933894#13933894 )
Julien Phalip
Anssi Kääriäinen
> On Dec 18, 2012, at 5:18 AM, Emil Stenström <e...@kth.se> wrote:
>
> > On Monday, 2 June 2008 02:45:07 UTC+2, Ludvig Ericson wrote:
> > I'd rather see this be leaved as-is, since I haven't seen a single
> > report on these broken pipe 'issues'.
>
> > Here's a report:
>
> > I'm using PhantomJS (headless webkit browser) to test for javascript errors on my site. Using the LiveServerTestCase it's possible to spawn a test server, and using Python's subprocess I can call PhantomJS to access that server and assert that there are no errors.
>
> > Problem is, the test server is spitting back broken pipe errors. By reading explanations elsewhere I've understood that this is a browser problem, that they are not supposed to break connections like that, but the fact is that they are. It feels strange to read recommendations that I should just ignore the errors, since having random stacktrace printouts in my tests feels extremely sloppy.
>
> > Given that browsers behave like they do, and we're not able to change that, I suggest that ticket #4444 is reconsidered, and no marked as wontfix.
>
> > As a workaround I would have hoped for a way to ignore the messages in some other way. I've tried setting up logging to ignore the errors, but failed. My guess is that these errors don't go through the logger. Maybe this couple me the recommended (and documented) way of handling this?
>
> Those errors are indeed extremely noisy and confusing. I'm in favor of modifying Django to reduce that noise, but only if it gets proven that ignoring those errors won't either cause the tests to fail or to pass as false positives.
in favour of silencing or just reporting "Broken pipe" without
stacktrace.
Does anybody know of situations where silencing the broken pipe errors
would lead to missing actual errors?
- Anssi