Cache-control header in mock response is fooled when cache-control header is specified in the request

[gmiam]

Hello deer and lovely Maintainer 👋

Not sure this is relevant, but: I'm using stubr in a very simple way so far. I'm starting the docker images as stated in the README with very simple mocks in a dedicated directory.

It seems that if we put a cache-control header in a response mock, when the cache-control header is specified in the request, it mess with the response header.

As a minimum repro case, I have this JSON mock

{
        "request": {
                "method": "GET",
                "urlPathPattern": "/blank_vary/(.*)"
        },
        "response": {
                "body": "Hello stubr - no vary",
                "headers": {
                        "Vary": "",
                        "Cache-Control": "test"
                }
        }
}

If I perform the following curl command, with no cache-control of my own
curl -vvv http://stubr.rs:9191/blank_vary/test

*   Trying 127.0.0.1:9191...
* Connected to stubr.rs (127.0.0.1) port 9191 (#0)
> GET /blank_vary/test HTTP/1.1
> Host: stubr.rs:9191
> User-Agent: curl/7.79.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< cache-control:  s_maxage=66666, no-cache, no-store, no-transform, must_revalidate, proxy-revalidate, must-understand, private, public, immutable, stale-while-revalidate=86400, stale-if-error, max-age=2
< vary:
< content-type: text/plain
< server: stubr(0.4.13)
< content-length: 21
< date: Tue, 18 Oct 2022 20:59:29 GMT
<
* Connection #0 to host stubr.rs left intact
Hello stubr - no vary%                                                          

It works!

The same with a void cache-control header
curl -vvv -H "Cache-Control: " http://stubr.rs:9191/blank_vary/test

*   Trying 127.0.0.1:9191...
* Connected to stubr.rs (127.0.0.1) port 9191 (#0)
> GET /blank_vary/test HTTP/1.1
> Host: stubr.rs:9191
> User-Agent: curl/7.79.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< cache-control:  s_maxage=66666, no-cache, no-store, no-transform, must_revalidate, proxy-revalidate, must-understand, private, public, immutable, stale-while-revalidate=86400, stale-if-error, max-age=2
< content-type: text/plain
< server: stubr(0.4.13)
< vary:
< content-length: 21
< date: Tue, 18 Oct 2022 21:00:26 GMT
<
* Connection #0 to host stubr.rs left intact
Hello stubr - no vary%                                                          

Still works!

But if I have any content in the cache-control header, then the first directive (and only the first) from the request is reused in the cache-control header of the response.
curl -vvv -H "Cache-Control: test1, test2" http://stubr.rs:9191/blank_vary/test

*   Trying 127.0.0.1:9191...
* Connected to stubr.rs (127.0.0.1) port 9191 (#0)
> GET /blank_vary/test HTTP/1.1
> Host: stubr.rs:9191
> User-Agent: curl/7.79.1
> Accept: */*
> Cache-Control: test1, test2
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< server: stubr(0.4.13)
< vary:
< cache-control: test1
< content-type: text/plain
< content-length: 21
< date: Tue, 18 Oct 2022 21:01:41 GMT
<
* Connection #0 to host stubr.rs left intact
Hello stubr - no vary% 

We now have cache-control: test1 in the response. I confirm that if I change my request header, it changes the resposne one.

I don't know if it something that is fixable on stubr side, but let's hope 😄

[beltram]

Thanks for reporting 😄
It was caused by the backing hyper server replaying cache control request headers in responses, which is not ideal for a stub server where you are more willing for strict control.
This is now fixed