bneradt edited a comment on issue #7880:
URL: https://github.com/apache/trafficserver/issues/7880#issuecomment-849062280


   I'm working on reproducing this but haven't been able to yet. We have a 
negative-revalidating test which I've modified like so:
   
   ```$ git diff
   diff --git a/tests/gold_tests/cache/negative-revalidating.test.py 
b/tests/gold_tests/cache/negative-revalidating.test.py
   index 1f4975206..901e65f95 100644
   --- a/tests/gold_tests/cache/negative-revalidating.test.py
   +++ b/tests/gold_tests/cache/negative-revalidating.test.py
   @@ -56,7 +56,14 @@ ts.Disk.records_config.update({
        # Negative revalidating is on by default. Verify this by leaving out the
        # following line and expect negative_revalidating to be enabled.
        # 'proxy.config.http.negative_revalidating_enabled': 1,
   -    'proxy.config.http.cache.max_stale_age': 6
   +    'proxy.config.http.cache.max_stale_age': 6,
   +
   +    # From issue.
   +    'proxy.config.http.negative_revalidating_lifetime': 0,
   +    'proxy.config.http.chunking_enabled': 1,
   +    'proxy.config.http.chunking.size': 4096,
   +    'proxy.config.http.keep_alive_no_activity_timeout_in': 10,
   +
    })
    tr = Test.AddTestRun("Verify negative revalidating behavior.")
    replay_file = "replay/negative-revalidating-enabled.replay.yaml"
   diff --git 
a/tests/gold_tests/cache/replay/negative-revalidating-enabled.replay.yaml 
b/tests/gold_tests/cache/replay/negative-revalidating-enabled.replay.yaml
   index 3fdb97149..aa660764b 100644
   --- a/tests/gold_tests/cache/replay/negative-revalidating-enabled.replay.yaml
   +++ b/tests/gold_tests/cache/replay/negative-revalidating-enabled.replay.yaml
   @@ -42,8 +42,9 @@ sessions:
          reason: "OK"
          headers:
            fields:
   -        - [ Content-Length, 32 ]
            - [ Cache-Control, max-age=2 ]
   +      content:
   +        size: 3200
    
        proxy-response:
          status: 200
   ```
   
   That's a modification of this test:
   
https://github.com/apache/trafficserver/blob/050b2dfe9a89348b4105183a2b31e7cc59fc389d/tests/gold_tests/cache/negative-revalidating.test.py
   
   Note I modified the server to not contain a content-length header in its 
response and I increased the body size to be greater than 2048 (3200 bytes). I 
then ran the test. The first three transactions do this:
   
   1. Populate the cache with a response to a GET request.
   2. Repeat the GET immediately request and make sure it is served out of 
cache when the resource is not stale.
   3. Wait 4 seconds so that the cached resource is stale (greater than the 2 
second max-age), but younger than max_stale_age.
   4. Repeat the GET.
   5. Server responds with a 503.
   6. ATS replies out of cache due to negative_revalidating.
   
   Looking at the proxy verifier output, I see the following:
   1. The very first response is chunked encoded from ATS with a c80 chunk 
header (hex for 3200).
   2. The second one, responded out of cache while not stale, has a 
content-length field value of 3200.
   3. The third one is served out of the cache while stale due to negative 
revalidating, and it is chunk encoded and has the appropriate trailer:
   
   ```
      [0]: Received an HTTP/1 200 response for key 3 with headers:
   - "cache-control": "max-age=2"
   - "Date": "Wed, 26 May 2021 19:02:26 GMT"
   - "Expires": "Wed, 26 May 2021 19:02:31 GMT"
   - "Transfer-Encoding": "chunked"
   - "Connection": "keep-alive"
   - "Server": "ATS/10.0.0"
   
      [0]: Drained 3200 chunked body bytes with chunk stream: c80^M
   0000000 0000001 0000002 0000003 0000004 0000005 0000006 0000007 0000008 
0000009 000000a 000000b 000000c 000000d 000000e 000000f 0000010 0000011 0000012 
0000013 0000014 0000015 0000016 0000017 0000018 0000019 000001a 000001b 000001c 
000001d 000001e 000001f
   0^M
   ^M
   
   ```
   
   The line with the chunk body is truncated to the width of my terminal, thus 
it doesn't contain all 3200 characters. But note that it does have the 
zero-lengthed chunk trailer in this case.
   
   I repeated the test by hand, now taking down the server so it is not 
reachable rather than having it reply with a 503. This time, when the server 
was down and the resource was greater than Cache-Control's max-age but less 
than max_stale_age, I notice that it replies with a content-length of 3200 
rather than chunked encoding.
   
   Anyway, that's what I've tried so far. I'll keep thinking about what else to 
try to fit @lukenowak 's setup.
   
   @lukenowak : if reading the above you notice any configuration or behavior I 
might be missing to reproduce this, please let me know.
   
   Thanks.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to