support of static response payload

[Asisranjan]

How do i configure response payload in test server so that any request to test server would return status code, header along with given response payload

Will appreciate for any help.

[oschaaf]

Sample configuration fragment from here:

          - name: test-server   
            config:
              response_body_size: 10
              response_headers:
              - { header: { key: "foo", value: "bar"} }
              - { header: { key: "foo", value: "bar2"}, append: true }
              - { header: { key: "x-nh", value: "1"}}

You can indicate the size (10 in this example) for the response payload, but not the specific contents today. For indicating response code status, I think this will work:

- { header: { key: ":status", value: "202"}}

[Asisranjan]

Hi @oschaaf Thanks for reply!

my application acts as middle ware; based on response content we are processing additional functionality such as database update, metrics etc.

I think it is a new change..can you please guide what needs to be done in this case

[oschaaf]

Currently the size of the request content body is determined here:

https://github.com/envoyproxy/nighthawk/blob/5652d351364ce31e819b8824e748b3c1741ed6a1/source/client/benchmark_client_impl.cc#L154

Subsequently a request body sized accordingly to that is inserted here: https://github.com/envoyproxy/nighthawk/blob/5652d351364ce31e819b8824e748b3c1741ed6a1/source/client/stream_decoder.cc#L86

The content of the request body is based on the contents of staticUploadContent().data(). The quickest solution would be to make a direct change there to support the dynamic request data that you are after.

Having said that, I think that ideally Requestimpl / StaticRequestSource would be modified/extended to take ownership of the request entity body content generation. Over at https://github.com/envoyproxy/nighthawk/blob/5652d351364ce31e819b8824e748b3c1741ed6a1/source/client/benchmark_client_impl.cc#L165 we would then pass request instead of request->header() to the StreamDecoder constructor, and the StreamDecoder implementation would then consume the header and body contents through the Request interface.

Regardless of the above approaches, this would also need configuration option(s). Looking at an earlier PR which adds a configuration option may be helpful, e.g. see this example