Based on the BES context max_response_size being set to 100 (kilobytes) this request should be rejected:
But it is not. Why? Can we fix it?
So in a very interesting turn of events I find that when the OLFS issues this command:
The command succeeds and all of the requested data are returned. This is incorrect behavior because the max_response_size is set to 10k bytes and the size of the (binary DAP2) response is 761k bytes.
However, when issued via bescmdln to the same besd/beslistener(master) or via besstandalone it works, as in the correct BES error is returned.
Correct BES Error response:
While working on a different ticket I ran the OLFS regression tests while my the max_response_size was set to 10kb. Some tests actually failed (odd...)
But even more interesting is the error messages are inconsistent.
The DAP2 error message looks like:
But the DAP4 error message is messed up:
I've added some handwritten tests based on the coads dataset use above and for both dods and ascii DAP2 responses, the request_limit context works. It works from both besstandalone and using bescmdln. E.G:
DAP4 is a different story. It seems broken in how it uses the context value and in how it computes request sizes. More work needed there...
The get_request_size(true) and get_response_limit() code mixes Bytes and KB.
I have DAP4 sorted, but not DAP4 --> ascii.
See the response-limit-fix branch for WIP
I think it's important to test this with the OLFS too, as it seems there is some kind of messed up state persistence happening that may be part of the mysterious behavior where the OLFS issues the command over an existing connection and max_response_size is ignored, but when new connections are made using bescmdln and besstandalone the same command works as expected.