Add tests for interim response handling #147
Open
+420
−9
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
During one of the HTTP WG session at the IETF 121 meeting in Dublin, resumable uploads was discussed and the topic of support for interim responses in the current HTTP ecosystem came up. @mnot suggested that the cache-tests could be used to test how proxies handle interim responses.
This PR takes a first stab at this. It implements two tests for the 102 and 103 status codes. I would have liked to test an informational status code that is not yet registered to ensure that proxies don't limit their behavior to specific status codes, but currently Node.js' http module does not support sending arbitrary interim responses (see nodejs/node#27921 (comment)). The tests check that proxies pass interim responses through, but are still able to cache the final response.
So far, support for this is varying:
I can imagine that some of these failures are due to missing configuration settings. For example, for Nginx it was necessary to enable HTTP/1.1 to the origin. Otherwise it fell back to HTTP/1.0 which does not support interim responses as far as I know.
To accommodate the new tests, the
interim_response
andexpected_interim_responses
configurations have been added. Since the Fetch API itself does not expose interim responses to the caller, they have to be collected using the ability to intercept dispatcher in Node.js'undici
module, which is the implementation behind Node's Fetch API. See https://undici.nodejs.org/#/docs/api/Dispatcher?id=dispatchercomposeinterceptors-interceptor for more details.I would be happy for any feedback regarding the tests themselves, as well as the code changes.