add additional buffer limit test cases #247
Open
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.
When looking into traefik/traefik#10687, I came across some interesting behavior where the buffer changes from returning a 200 to a 500 depending on the configured limits, but then also changes back and forth when crossing a size equal to a multiple of 32768 bytes.
For instance, the traefik issue configures a buffer that only sets the
maxResponseBodyBytes
option to a value of 2000 bytes. For response sizes from 1 up to 2000 bytes, the buffer behaves correctly and returns a 200 status which is expected. From 2001 up to 32768, the buffer returns a 500 status which is also expected. From 32769 up to 34769 (32769 + 2000) the buffer changes back to returning a 200 status, which I don't think is the expected behavior. From 34769 up to 65538 the behavior changes back to a 500, and so on at size boundaries equal to multiples of 32768.This PR is not mean to be merged in its current state, but adds a handful of test cases that demonstrate the observed behavior. Based on my understanding of the expected behavior, each case should result in a 500 response, but a few of them result in unexpected 200 responses.