Re: NSURLConnection callbacks in the presence of errors
Re: NSURLConnection callbacks in the presence of errors
- Subject: Re: NSURLConnection callbacks in the presence of errors
- From: Jens Alfke <email@hidden>
- Date: Thu, 09 Jan 2014 13:54:55 -0800
We're trying to diagnose some gnarly Wi-Fi and BLE issues, but one question that came up is what happens when some data gets transferred, and then an error occurs?
You’ll get a didFailWithError call. You might get didReceiveResponse and didReceiveData first, depending on how early the error occurred.
Promiscuous packet sniffing showed data packets going over before the connection falls apart, but I don't get called back with any of that data.
Is NSURLConnection waiting to buffer enough data, and just calling the -…didFailWithError: without first calling the other methods when data is received?
Probably. It obviously has to wait until it’s received the response status line and all the headers, before calling didReceiveResponse. It might have to buffer up some data if the response is gzipped. And it probably buffers data just to avoid having to call your didReceiveData with lots of tiny blocks.
Oh, I just remembered — if the response is chunked, NSURLConnection will buffer up the _entire_ response before decoding it and sending it to your delegate. This is a bug, and I filed a bug report a year or two ago. It increases latency and memory usage, perhaps severely if the response is large. Worse, if the response is an endless open-ended data stream (like a CouchDB _changes feed) you never get a response at all, because there’s no EOF. There’s no workaround for this that I know of.
—Jens |
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden