Re: [whatwg/fetch] Streaming upload (Issue #1438)

>  all I'm suggesting is to not treat step 6 differently than step 7, and to not change the flow in some cases and not others, but to do for step 6 the same as for step 7, which also matches the flow for downstream. Is that a possible compromise?

I don't understand your proposal. Step 6 and step 7 are different option values representing different behaviors.

> I'm not sure I understand your response "ok to implement this case" correctly. Were you saying that you would ensure that a 401 is handled and passed on immediately? As a special case?

I said I was happy to cancel the session when we see 401 (as well as redirects).
That's actually specced now.

https://fetch.spec.whatwg.org/#http-network-or-cache-fetch


14. If response’s [status](https://fetch.spec.whatwg.org/#concept-response-status) is 401, httpRequest’s [response tainting](https://fetch.spec.whatwg.org/#concept-request-response-tainting) is not "cors", includeCredentials is true, and request’s [window](https://fetch.spec.whatwg.org/#concept-request-window) is an [environment settings object](https://html.spec.whatwg.org/multipage/webappapis.html#environment-settings-object), then:
      1. ...
      2. If request’s [body](https://fetch.spec.whatwg.org/#concept-request-body) is non-null, then:
          1. If request’s [body](https://fetch.spec.whatwg.org/#concept-request-body)’s [source](https://fetch.spec.whatwg.org/#concept-body-source) is null, then return a [network error](https://fetch.spec.whatwg.org/#concept-network-error).

Working with redirects / authentication requests is difficult because for non-streaming requests we repeat the request body. We don't want to store the entire stream for potential redirects / authentication requests, so we decided to cancel the requests in such cases. Of course, it is open to extention, so if you want to add an alternative behavior, please feel free to file an issue.

> In other words, whatever the API, the browser cannot sit on server errors, but needs to report them back as soon as the server sends them. This is true even for non-live streams. Streams are unnecessary for a few KB, but they can be very long, even hours of upload. To ignore errors and pass them on only after the stream ends, is way too late, causes useless re-transmisssion of large files at best, or even data loss. I cannot see any other solution than what I proposed. Or maybe you have something in mind how to solve this?

This is true, but this is generally true for requests with big bodies. The server can send a response and reset the stream when it thinks it doesn't need furthur request body.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1438#issuecomment-1161880265

You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1438/1161880265@github.com>