I was testing a HTTP servlet implementation (kindly shared by BalusC) which supports HTTP byte range requests.
I have found some peculiar differences between differe
IIRC, "broken pipe" simply means the other side received data after it closed its read end.
The most reasonable thing I can think of is that it's an attempt to not waste large amounts of bandwidth downloading video that never gets watched (perhaps something they've agreed with carriers, which I suspect is the reasoning behind the "live streaming" restriction:
"Video streaming content over a cellular network longer than 10 minutes must use HTTP Live Streaming and include a baseline 64 kbps audio-only HTTP Live stream."
The only other easy way to throttle the download is to stop read()
ing and wait for the receive window to fill up, but that's not always easy to do (NSURLConnection
really doesn't make this easy, for example).
If you're exceptionally lucky, the client will close its write end (such that the server will read()
EOF) and wait for a little while before closing its read end. In this case, it might be safe to assume that the client no longer wants the rest of the download. RFC 2616 is a little hazy (it seems to forget that sockets can be closed in only one direction) but mentions "graceful close" (which according to Microsoft involves closing the write side and finishing reading from the read side until a timeout passes), but also says
Servers SHOULD NOT close a connection in the middle of transmitting a response, unless a network or client failure is suspected.
So if you know it's an iDevice and you read EOF, then it might be safe for the server to close the socket, provided you've thoroughly tested that it doesn't break anything — changing HTTP behaviour depending on User-Agent just seems like a terrible idea.
Alternatively, don't care. You can do U-A sniffing and ignore the exception if it's an iDevice (which seems less terrible than changing HTTP behaviour). The exception overhead is almost certainly negligible, and probably far lower than the overhead of printing it to a log. 100 exceptions a second is nothing. Profile it if you're unsure.
You could also file a bug with Apple, but as these things go, it's not particularly dubious network behaviour.