sending a file through sockets

[Bryan Olson]

Donn Cave wrote:
 > Quoth Bryan Olson:
 > | Donn Cave wrote:
 > ...
 > |> Part of my job is to decide
 > |> how robust an application needs to be, and while it may be good to
 > |> err on the side of safety, that doesn't excuse me from making the 
call.
 > |
 > | For an internet application, it turns out to be more than most people
 > | think.  It's a rough network out there.
 >
 > I'm going to try one last time to clarify my point here: it _depends_
 > _on_ _the_ _application_.

Are you willing to consider other points?  It also depends upon _the_
_environment_.   Very frequently, programs that worked fine within an
enterprise fail on the internet.

If I were giving hints on writing "my first Internet application", one
would be *not* to do it at the sockets level.


 > Some applications need to be as bomb-proof
 > as possible, but many others don't.  That isn't because they're not
 > "professional", or not "real", it's because the risk is a tolerable
 > trade-off for the complexity of a bomb-proof solution.

Many times we've seen news-worthy failures of internet applications.
Report often include the fact that flaw was already well-known.  People
wonder how the creators could be so irresponsible as to deploy programs
with known, fixable, defects.


 > | I welcome you to send a byte count.  I didn't even say it was bad
 > | advice; just that it's not really needed, and since the protocol
 > | didn't check it, we might as well take it out.  To me, this one looked
 > | like a job for HTTP/0.9.
 >
 > If you ever get your hands an actual application that sends a byte
 > count but doesn't look at it on the other end - leave it alone.

Well of course I've gotten my hands on such things.  Most web browsers
don't use the "content-length" in a text/html response over HTTP/1.0.
That's recommended practice by RFC 1945, because a number of buggy
servers computed the length before adding server-side includes.


--Bryan