-
Notifications
You must be signed in to change notification settings - Fork 5
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
Clarify the behaviour of Javascript Validation when we are waiting for the full body #38
Comments
I think you understood it correctly. I think we have to change the test. I suspect that instead of returning a response with an infinitely streaming body we'd instead hit a network timeout. |
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this issue
Jan 9, 2023
…l.any.js r=smaug One of the subtests (Underlying connection is closed when aborting after receiving response - no-cors) creates an fetch request with infinite response, and it expects the promise of this fetch will be resolved while the server is still responding, however, this behavior is not compatible with ORB. See annevk/orb#38 for more details. I am disabling the JS validator for these tests, we could change the ini file to mark them as TIMEOUT, since the test has `// META: timeout=long`, it takes a very long time to timeout. Once annevk/orb#38 is resolved, we can enable the JS validator for them. Differential Revision: https://phabricator.services.mozilla.com/D166180
jamienicol
pushed a commit
to jamienicol/gecko
that referenced
this issue
Jan 13, 2023
…l.any.js r=smaug One of the subtests (Underlying connection is closed when aborting after receiving response - no-cors) creates an fetch request with infinite response, and it expects the promise of this fetch will be resolved while the server is still responding, however, this behavior is not compatible with ORB. See annevk/orb#38 for more details. I am disabling the JS validator for these tests, we could change the ini file to mark them as TIMEOUT, since the test has `// META: timeout=long`, it takes a very long time to timeout. Once annevk/orb#38 is resolved, we can enable the JS validator for them. Differential Revision: https://phabricator.services.mozilla.com/D166180
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There is test which expects the
window.fetch
to be resolved while the server is sending the response. If ORB is compatible with this behaviour, then it means ORB will allow the promise to resolve before it has made its decision about this request, otherwise this test would hang because ORB will wait for the full response indefinitely.This contradicts to
The promise should throw if it's blocked by ORB
.The current spec text for consuming the body stream for ORB is
Fully read response’s body given processBody and processBodyError
would return afully read body as promise
andresponseBodyBytes
would be non-null when thefull read body promise
is resolved. So this is a blocking behaviour (thanks @annevk for clarifying this). However, this blocking behaviour contradicts to the test that I linked.Should we allow the promise to be resolved first and only allow the body stream to be consumed if ORB allows this request?
Let me know if I misunderstand something.
The text was updated successfully, but these errors were encountered: