Merge pull request #2283 from leviding/patch-31

FIX: some typo error

1-js/12-generators-iterators/2-async-iterators-generators/article.md

@@ -363,7 +363,7 @@ More explanations about how it works:
     - The initial URL is `https://api.github.com/repos/<repo>/commits`, and the next page will be in the `Link` header of the response.
     - The `fetch` method allows us to supply authorization and other headers if needed -- here GitHub requires `User-Agent`.
 2. The commits are returned in JSON format.
-3. We should get the next page URL from the `Link` header of the response. It has a special format, so we use a regular expression for that (we will lern this feature in [Regular expressions](info:regular-expressions)).
+3. We should get the next page URL from the `Link` header of the response. It has a special format, so we use a regular expression for that (we will learn this feature in [Regular expressions](info:regular-expressions)).
     - The next page URL may look like `https://api.github.com/repositories/93253246/commits?page=2`. It's generated by GitHub itself.
 4. Then we yield the received commits one by one, and when they finish, the next `while(url)` iteration will trigger, making one more request.
 

5-network/04-fetch-abort/article.md

@@ -26,7 +26,7 @@ When `abort()` is called:
 
 Generally, we have two parties in the process: 
 1. The one that performs an cancelable operation, it sets a listener on `controller.signal`.
-2. The one one that cancels: it calls `controller.abort()` when needed.
+2. The one that cancels: it calls `controller.abort()` when needed.
 
 Here's the full example (without `fetch` yet):
 

5-network/06-fetch-api/article.md

@@ -217,8 +217,8 @@ Normally, when a document is unloaded, all associated network requests are abort
 
 It has a few limitations:
 
-- We can't send megabytes: the body limit for `keepalive` requests is 64kb.
+- We can't send megabytes: the body limit for `keepalive` requests is 64KB.
     - If we need to gather a lot of statistics about the visit, we should send it out regularly in packets, so that there won't be a lot left for the last `onunload` request.
-    - This limit applies to all `keepalive` requests together. In other words, we can perform multiple `keepalive` requests in parallel, but the sum of their body lengths should not exceed 64kb.
+    - This limit applies to all `keepalive` requests together. In other words, we can perform multiple `keepalive` requests in parallel, but the sum of their body lengths should not exceed 64KB.
 - We can't handle the server response if the document is unloaded. So in our example `fetch` will succeed due to `keepalive`, but subsequent functions won't work.
     - In most cases, such as sending out statistics, it's not a problem, as server just accepts the data and usually sends an empty response to such requests.

5-network/10-long-polling/article.md

@@ -70,7 +70,7 @@ As you can see, `subscribe` function makes a fetch, then waits for the response,
 ```warn header="Server should be ok with many pending connections"
 The server architecture must be able to work with many pending connections.
 
-Certain server architectures run one process per connection; resulting in there being as many processes as there are connections, while each process consumes quite a bit of memory. So, too many connections will just consume it all.
+Certain server architectures run one process per connection, resulting in there being as many processes as there are connections, while each process consumes quite a bit of memory. So, too many connections will just consume it all.
 
 That's often the case for backends written in languages like PHP and Ruby.
 

9-regular-expressions/10-regexp-greedy-and-lazy/1-lazy-greedy/task.md

@@ -3,5 +3,5 @@
 What's the match here?
 
 ```js
-"123 456".match(/\d+? \d+?/g) ); // ?
+alert( "123 456".match(/\d+? \d+?/g) ); // ?
 ```