Fastolfe has some good comments, but I want to expand a bit. There are additional reasons it might be necessary to turn off buffering:
First, if you have a potentially slow connection, and it could take longer than your timeout to generate enough information to fill the buffer.
Second, if the information you send has a positional aspect (as in, the HTTP headers must precede the content). If the potential exists that an error message may go out before the full headers, you may disable buffering.
The disclaimer, of course, is that I'm not an expert here. :) | [reply] [Watch: Dir/Any] |
Second, if the information you send has a positional aspect (as in, the HTTP headers must precede the content). If the potential exists that an error message may go out before the full headers, you may disable buffering.
This actually brings us to another caveat: Don't mix buffered and unbuffered output. If your script writes to STDOUT and STDERR, and both of these somehow find their way through the network connection, note that STDOUT is buffered by default but STDERR is not. This is why you'll occasionally see "errors" appear before the actual output. The output is being mixed and naturally buffered output will appear later.
| [reply] [Watch: Dir/Any] |
Enabling autoflush is the same as setting $|=1. IO::Socket automatically sets autoflush mode on a created socket, so you shouldn't have to do it.
If you're pushing large amounts of data, perhaps it's useful to have this turned off to take advantage of IO buffering, but for most network tasks, it's good to leave this turned on. | [reply] [Watch: Dir/Any] [d/l] |