-
Notifications
You must be signed in to change notification settings - Fork 341
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
redirect doesn't cancel or consume current response #1288
Comments
I'm not sure how much we want to say about this, though perhaps we should add some wording. A lot of this depends on the HTTP version. |
I think you want to cancel/end/abort the response stream in some way regardless of http version? Maybe just write "cancel response stream" and leave what that means as an implementation detail? |
Step 8 of https://fetch.spec.whatwg.org/#http-fetch does something like that. #637 is about making that version-agnostic. This request is slightly different I suppose in that you are asking for mandatory behavior which is not unreasonable. We'd need everyone to agree on what that behavior should be though. |
Ah, you mean:
Not sure why the "status is not 303" pre-condition exists? A 303 response may also contain a body if the server doesn't follow spec. |
In terms of "needs implementer interest" I can add Node to that list. I'm working on implementing fetch for nodejs through https://github.com/nodejs/undici. |
The WHATWG working mode is about implementing specs in browser engines, so we need multiple browser engines interested in such a thing. |
I see. Was hoping Node could be included in the list as an "engine". I assume then that WHATWG has limited (if any) involvement in Node. |
Yeah, you can learn more about the WHATWG here: https://whatwg.org/faq#what-is-the-whatwg |
Likewise the 407 case does not cleanup the active response. |
Even though a server shouldn't send a body with a redirect response, it is still possible. The way the spec is defined we have a deadlock here if the connection is re-used where the redirect response body is waiting to be consumed but we discard the reference and start a new request (mainFetch). We should probably consume/cancel/abort current response body before calling mainFetch again.
We avoid the same issue with 427 by setting
forceNewConnection
inhttpNetworkOrCacheFetch
.The text was updated successfully, but these errors were encountered: