fixup: rephrase polishing

docs/user/learn/on-demand-downloading.md

@@ -78,13 +78,13 @@ There are two different types of errors that can occur with on-demand streaming:
 
 In the first case, Pulp will try all the available remote sources for the requested content and will return a 404 if all of them fail *with this same type of error*.
 
-In the second case, Pulp already sent the corrupted data to the client and can't recover from it, so it will close the connection to prevent the client from consolidation the file.
+In the second case, Pulp already sent the corrupted data to the client and can't recover from it, so it will close the connection to prevent the client from consolidating the file.
 When this happens, the content-app will ignore that remote source for a certain amount of time, which will enable future requests to select a different remote source.
-A 404 is returned if no more remote source is available (e.g., they're all ignored).
-Pulp doesnt't permanently invalidate the remote because it can't know if the error is transient or not.
+If all remote sources are ignored due to prior failure, then a 404 will be returned for all requests of that content until the cooldown period for one of those sources has expired.
+Pulp doesn't permanently invalidate the remote because it can't know if the error is transient or not.
 
 The second case is complex and can be confusing to the user.
-The core reason for this complexity lies on the very nature of on-demand serving, which imposes that Pulp must fetch and stream the content on request time, and has no way to know anything about the remote before that.
+The core reason for this complexity lies in the very nature of on-demand serving, which imposes that Pulp must fetch and stream the content on request time, and has no way to know anything about the remote before that.
 This constraint great limits the range of actions Pulp can do to properly satisfy the request.
 
 If this behavior is prohibitive, consider using the immediate sync policy.