https keepalive and chunking disabled problem

[esmq2092]

when original server return chunk encoding but ats disabled chunking at all... ats(7.0.0) have to close the client connection when transaction had done...(all i mention here are cache miss requests)，

there's no problem for http requests, but i observed strange behavior for https request when use different version of wget as user-agent...

---

1) Wget/1.12 + http1.0 + keepalive, it works fine... GET /? HTTP/1.0 User-Agent: Wget/1.12 (linux-gnu) Accept: / Host: a.b.com Connection: Keep-Alive

2) when switch to Wget/1.16 + http1.1 + keepalive, error occurs.... GET /? HTTP/1.1 User-Agent: Wget/1.16 (linux-gnu) Accept: / Host: a.b.com Connection: Keep-Alive

it will cause infinite loop generating error message like this : Read error at byte 39814 (The TLS connection was non-properly terminated.).Retrying.

and i known this message is actually emit by gnutls, both gnutls 3.0.22 and 3.3.8 have the problem....

3) when switch to Wget/1.16 + http1.1 and without keepalive, the problem gone....

when turn on chunking can fix the problem, still i want to known that is the problem about ats or gnutls ?

[esmq2092]

when follow conditions are met, the gnutls will emit error message

1) original server return chunking data 2) ats configure to disable chunking at all 3) http1.1 client and use Keep-Alive connection 4) client build with gnutls 5) https request

[bryancall]

Linked with #1651

[bryancall]

We should verify the configuration options are working correctly for the 9.0.0 release.

[bryancall]

The configuration option in question is proxy.config.http.chunking_enabled(https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html?highlight=chunking#proxy.config.http.chunking_enabled)

[bneradt]

@esmq2092 : Thank you for filing this issue.

I've added a few tests where ATS is configured to not respond with chunked content and the client initiates the transaction with "Connection: Keep-Alive": https://github.com/apache/trafficserver/pull/7743

ATS seems to behave as expected:

• It does not reply with a chunked-encoded response.
• It includes a connection-close header.

Our Proxy Verifier test client experiences no issues with the responses.

My first request to you: can you please review that test in the PR, looking particularly at the ATS configuration, and verify that it has the configuration you expect would be needed to reproduce the problem you explain here? I believe it does per my reading of this issue, but it wouldn't hurt to double-check my work.

Second: with this configuration, I also tried reproducing the wget issue you experienced by performing requests against ATS proxying to this same test server. It had the same configuration, and the test server replied with a chunked response. I could not reproduce the issue though. In addition to checking my ATS configuration, can you please provide me your wget command line invocation? Here was mine:

$ wget --version
GNU Wget 1.14 built on linux-gnu.

+digest +https +ipv6 +iri +large-file +nls +ntlm +opie +ssl/openssl 

Wgetrc: 
    /etc/wgetrc (system)
Locale: /usr/share/locale 
Compile: gcc -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/etc/wgetrc" 
    -DLOCALEDIR="/usr/share/locale" -I. -I../lib -I../lib -O2 -g -pipe 
    -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
    --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic 
Link: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
    -fstack-protector-strong --param=ssp-buffer-size=4 
    -grecord-gcc-switches -m64 -mtune=generic -lssl -lcrypto 
    /usr/lib64/libssl.so /usr/lib64/libcrypto.so /usr/lib64/libz.so 
    -ldl -lz -lz -lidn -luuid -lpcre ftp-opie.o openssl.o http-ntlm.o 
    ../lib/libgnu.a 

Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://www.gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Originally written by Hrvoje Niksic <hniksic@xemacs.org>.
Please send bug reports and questions to <bug-wget@gnu.org>.

$ wget --header "uuid: 2" --header "Connection: Keep-Alive" --no-check-certificate https://localhost:61012/for/https                                                                                                                               
--2021-04-23 23:14:48--  https://localhost:61012/for/https
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:61012... failed: Connection refused.
Connecting to localhost (localhost)|127.0.0.1|:61012... connected.
WARNING: cannot verify localhost's certificate, issued by ‘/C=IE/ST=Dublin/L=Dublin/O=example.com/OU=example.com/CN=example.com’:
  Self-signed certificate encountered.
    WARNING: certificate common name ‘example.com’ doesn't match requested host name ‘localhost’.
HTTP request sent, awaiting response... 200 OK
Length: unspecified
Saving to: ‘https’

    [ <=>                                                                                                                                                                                                      ] 32          --.-K/s   in 0s      

2021-04-23 23:14:48 (1.63 MB/s) - ‘https’ saved [32]

$ cat https
0000000 0000001 0000002 0000003 $

As you can see, I have wget 1.14 instead of 1.16. I'm not sure whether that could be the significant difference.

[bneradt]

ATS seems to behave as expected per the new #7743 test. I was not able to reproduce the client issue. Considering the age of this bug and no one else reporting issues on this, I'm going to clean things up by closing this bug. Please re-open if issues of this nature are seen again.