-
Notifications
You must be signed in to change notification settings - Fork 55
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
Consider running browser tests against FetchRequest
in addition to XHRRequest
#1772
Labels
testing
Includes all kinds of automated tests, the way that we run them and the infrastructure around them.
Comments
lawrence-forooghian
added
the
testing
Includes all kinds of automated tests, the way that we run them and the infrastructure around them.
label
May 21, 2024
lawrence-forooghian
added a commit
that referenced
this issue
May 21, 2024
It currently checks for the presence of a Content-Type response header and if present assumes that trying to parse the response will succeed. Realtime currently sends a 204 (No Content) with a Content-Type header from the POST rest.ably.io/push/publish endpoint when using HTTP 1.1 (see REA-1924). (This bug hasn't been caught by the tests because I guess most of the time they use HTTP 2 in browsers, and also we don't use FetchRequest in the tests except briefly in those for the modular variant of the library. I’ve created #1772 for improving this situation). The 204 handling approach is copied from that which we already have in XHRRequest. Resolves #1771.
lawrence-forooghian
added a commit
that referenced
this issue
May 21, 2024
It currently checks for the presence of a Content-Type response header and if present assumes that trying to parse the response will succeed. Realtime currently sends a 204 (No Content) with a Content-Type header from the POST rest.ably.io/push/publish endpoint when using HTTP 1.1 (see REA-1924). (This bug hasn't been caught by the tests because I guess most of the time they use HTTP 2 in browsers, and also we don't use FetchRequest in the tests except briefly in those for the modular variant of the library. I’ve created #1772 for improving this situation). The 204 handling approach is copied from that which we already have in XHRRequest. Resolves #1771.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
testing
Includes all kinds of automated tests, the way that we run them and the infrastructure around them.
We do not currently exercise our
FetchRequest
class in the tests; they all use XHR, the only exception being some of the tests for the modular variant the SDK. This might be hiding bugs in theFetchRequest
implementation such as #1771. See if we could run the tests againstFetchRequest
as well as XHR, the same way we exercise all of the different transports in (some) tests.┆Issue is synchronized with this Jira Task by Unito
The text was updated successfully, but these errors were encountered: