1

I am currently working on a Django development. There is a problem, which isn't a true problem but very annoying. Often, when I try to debug my Django app by putting down some break points, I get this error at the server end:

error: [Errno 32] Broken pipe

After reading this other post, Django + WebKit = Broken pipe, I have learned that this has nothing to do with the server but the client browser used. Basically, what happened is that the browser has a http request timeout. If it doesn't receive a response within the timeout, it will close down the connection with the server.

I find this timeout isn't really needed, indeed causing headache, during debugging. Is there any way I can lift this timeout or increase it for my browser (Chrome)? Or maybe a substitute browser that doesn't have this constraint?

Note: Although I am using Django and have mentioned about it, this isn't a Django-related question. It's more like a question on how to make my debugging process more effective.

Community
  • 1
  • 1
tamakisquare
  • 16,659
  • 26
  • 88
  • 129
  • 1
    Try running with Fiddler between your client and server with the streaming mode off (default). Fiddler will keep the connection alive a lot longer than your browser is likely to. – EricLaw Jun 28 '11 at 21:45
  • @ericlaw-msft, thanks for the pointer. I like the idea of having a middle man in-between client and server to keep the connection alive for longer time. Let me give Fiddler a try and see how well it works for my purpose. Cheers. – tamakisquare Jul 01 '11 at 18:50
  • @ericlaw-msft, I just found that I can't use Fiddler because it supports Windows only and my development environment is Linux :( – tamakisquare Jul 01 '11 at 19:00
  • 1
    If you have any Windows box, you can point your Linux box's proxy settings at Fiddler. If you have no windows boxes at all, the program named Charles, running on Java, might work for you. – EricLaw Jul 02 '11 at 02:30

1 Answers1

1

I prefer using linux/unix curl command for debugging web applications. It's good approach, especially if you want to focus on some specific request, for example: POST does not work fine for some set of parameters, or cookies are not set as expected.

Of course it may take some time at the beginning to find out how to use it, but then, you will have a total control about every single piece of request: timeouts, cookies, headers and so on. It's very helpful, because you can be sure that what you wanted to send is actually sent (no additional data is added by the web browser).

omnomnom
  • 8,911
  • 4
  • 41
  • 50
  • you're right that _curl_ is also an option. I often use it to debug web services, in which case there's no client-end presentation that I need to be concerned with. But in this post what I really need is a way to see what my users would see while not getting http timeout error. _curl_ is working at a lower level (request&response level, as opposed to presentation level), so it's not that suitable for my purpose. – tamakisquare Jul 01 '11 at 18:55