Re: [whatwg/fetch] Limit the network stack replay cache on uploading if body is stream. (#1204)

@yutakahirano commented on this pull request.



> @@ -5061,6 +5061,13 @@ optional boolean <var>forceNewConnection</var> (default false), run these steps:
     <ul>
      <li><p>Follow the relevant requirements from HTTP. [[!HTTP]] [[!HTTP-SEMANTICS]] [[!HTTP-COND]] [[!HTTP-CACHING]] [[!HTTP-AUTH]]
 
+     <li><p> In resolving the HTTP request, there is an evitable situaion that the user agent must
+     resend the <var>request</var> body (e.g. socket time-out).
+     If <var>request</var>'s <a for=request>body</a> is non-null, and <var>request</var>'s
+      <a for=request>body</a>'s <a for=body>source</a> is null, there is an <a>implementation-defined</a>

-1 indent

> @@ -5061,6 +5061,13 @@ optional boolean <var>forceNewConnection</var> (default false), run these steps:
     <ul>
      <li><p>Follow the relevant requirements from HTTP. [[!HTTP]] [[!HTTP-SEMANTICS]] [[!HTTP-COND]] [[!HTTP-CACHING]] [[!HTTP-AUTH]]
 
+     <li><p> In resolving the HTTP request, there is an evitable situaion that the user agent must

> evitable

inevitable?

> @@ -5061,6 +5061,13 @@ optional boolean <var>forceNewConnection</var> (default false), run these steps:
     <ul>
      <li><p>Follow the relevant requirements from HTTP. [[!HTTP]] [[!HTTP-SEMANTICS]] [[!HTTP-COND]] [[!HTTP-CACHING]] [[!HTTP-AUTH]]
 
+     <li><p> In resolving the HTTP request, there is an evitable situaion that the user agent must
+     resend the <var>request</var> body (e.g. socket time-out).
+     If <var>request</var>'s <a for=request>body</a> is non-null, and <var>request</var>'s
+      <a for=request>body</a>'s <a for=body>source</a> is null, there is an <a>implementation-defined</a>
+      cache limit not to cache the entire <a for=request>body</a>'s stream. If the cache runs out,

I think "cache" is not good here. It is a storage providing a faster way to read/write, but a cache shouldn't provide additional functionality - we need to be able to do everything without cache.

In this case, without the storage we cannot resend the request body, so there is a functional difference, and hence it's not cache.

I  suggest using "buffer" instead of "cache".

> @@ -5061,6 +5061,13 @@ optional boolean <var>forceNewConnection</var> (default false), run these steps:
     <ul>
      <li><p>Follow the relevant requirements from HTTP. [[!HTTP]] [[!HTTP-SEMANTICS]] [[!HTTP-COND]] [[!HTTP-CACHING]] [[!HTTP-AUTH]]
 
+     <li><p> In resolving the HTTP request, there is an evitable situaion that the user agent must
+     resend the <var>request</var> body (e.g. socket time-out).
+     If <var>request</var>'s <a for=request>body</a> is non-null, and <var>request</var>'s
+      <a for=request>body</a>'s <a for=body>source</a> is null, there is an <a>implementation-defined</a>
+      cache limit not to cache the entire <a for=request>body</a>'s stream. If the cache runs out,
+      return a <a>network error</a>.

This paragraph sounds like a mixture of normative text and non-normative notes. How about the following?

The user agent may have a buffer of an implementation-defined size and store the part of request's body to the buffer, when request's body is non-null and its source is null. The user agent may use the buffer to re-send request's body to the network.

(note) The re-sending is needed when the connection is timed out, for example. If request's body is sent more than the buffer size, it leads to a network error.

(note) The buffer is not needed when request's body's source is non-null, because the body can be re-created from request's body's source.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1204#pullrequestreview-629766307