Bug #25192
closedradosgw: civetweb: redirect_to_https_port: no chunk, no close, no size.
0%
Description
Behavior of 12.2.5
rgw frontends = civetweb port=0.0.0.0:80r+443s
curl:
[k0ste@WorkStation ~]$ curl -v http://s3.e2e4.ru/ * Trying 193.150.124.9... * TCP_NODELAY set * Connected to s3.e2e4.ru (193.150.124.9) port 80 (#0) > GET / HTTP/1.1 > Host: s3.e2e4.ru > User-Agent: curl/7.61.0 > Accept: */* > < HTTP/1.1 302 Found < Location: https://s3.e2e4.ru:443/ * no chunk, no close, no size. Assume close to signal end < * Closing connection 0 real 0m40.020s user 0m0.006s sys 0m0.006s
Firefox:
Client can't close connection and make new request to "Location". I think 40s is client timeout.
Also I don't think civetweb should send port ":443" in "Location" header.
Files
Updated by Abhishek Lekshmanan over 5 years ago
- Assignee set to Abhishek Lekshmanan
Updated by Abhishek Lekshmanan over 5 years ago
on setting 80r, basically 302 is sent asking the client to redirect to the ssl port. Was an ssl certificate set correctly with the ssl_certificate option?
For me this is what I see when I follow redirects
$ curl -vLk http://foobar.radosgw:8000
Rebuilt URL to: http://foobar.radosgw:8000/
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
^M 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 10.x.x.x...
* TCP_NODELAY set
* Connected to x.x port 8000 (#0)
> GET / HTTP/1.1
> Host: foobar.radosgw:8000
> User-Agent: curl/7.61.0
> Accept: */*
>
< HTTP/1.1 302 Found
< Location: https://foobar.radosgw:8002/
* no chunk, no close, no size. Assume close to signal end
<
{ [0 bytes data]
^M 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0^M 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0
* Closing connection 0
* Issue another request to this URL: 'https://foobar.radosgw/'
* Trying 10.x.x.x...
* TCP_NODELAY set
* Connected to (10.x.x.x) port 8002 (#1)
..various tls messages as ssl connnection is made ...
* SSL certificate verify result: self signed certificate (18), continuing anyway.
} [5 bytes data]
> GET / HTTP/1.1
> Host: foobar.radosgw:8002
> User-Agent: curl/7.61.0
> Accept: */*
>
{ [5 bytes data]
< HTTP/1.1 200 OK
< x-amz-request-id: tx000000000000000000004-005b6c2bf9-3b99e-default
< Content-Type: application/xml
< Content-Length: 214
< Date: Thu, 09 Aug 2018 11:56:41 GMT
<
{ [5 bytes data]
^M100 214 100 214 0 0 195 0 0:00:01 0:00:01 --:--:-- 195
* Connection #1 to host f167.suse.de left intact
<?xml version="1.0" encoding="UTF-8"?><ListAllMyBucketsResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/"><Owner><ID>anonymous</ID><DisplayName></DisplayName></Owner><Buckets></Buckets></ListAllMyBucketsResult>
Updated by Abhishek Lekshmanan over 5 years ago
- Status changed from New to Need More Info
Updated by Konstantin Shalygin over 5 years ago
- File civetweb.pcap civetweb.pcap added
- File nginx.pcap nginx.pcap added
- File Selection_001.png Selection_001.png added
- File Selection_002.png Selection_002.png added
Sorry for long reply, perhaps missed notification.
I debugged deeper. The problem actually is why Civetweb waiting 30 seconds before send TCP FIN.
Compared with nginx:
on setting 80r, basically 302 is sent asking the client to redirect to the ssl port. Was an ssl certificate set correctly with the ssl_certificate option?
Yes. Look at total time.
[k0ste@WorkStation ~]$ time curl -vL http://s3.e2e4.ru/ * Trying 193.150.124.9... * TCP_NODELAY set * Connected to s3.e2e4.ru (193.150.124.9) port 80 (#0) > GET / HTTP/1.1 > Host: s3.e2e4.ru > User-Agent: curl/7.61.1 > Accept: */* > < HTTP/1.1 302 Found < Location: https://s3.e2e4.ru:443/ * no chunk, no close, no size. Assume close to signal end < * Closing connection 0 * Issue another request to this URL: 'https://s3.e2e4.ru:443/' * Trying 193.150.124.9... * TCP_NODELAY set * Connected to s3.e2e4.ru (193.150.124.9) port 443 (#1) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: none * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * ALPN, server did not agree to a protocol * Server certificate: * subject: OU=Domain Control Validated; OU=PositiveSSL Wildcard; CN=*.e2e4.ru * start date: Sep 11 00:00:00 2017 GMT * expire date: Sep 10 23:59:59 2020 GMT * subjectAltName: host "s3.e2e4.ru" matched cert's "*.e2e4.ru" * issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Domain Validation Secure Server CA * SSL certificate verify ok. > GET / HTTP/1.1 > Host: s3.e2e4.ru > User-Agent: curl/7.61.1 > Accept: */* > < HTTP/1.1 200 OK < x-amz-request-id: tx00000000000000002175e-005bb2eff1-d6b15d3-default < Content-Type: application/xml < Content-Length: 214 < Date: Tue, 02 Oct 2018 04:11:29 GMT < * Connection #1 to host s3.e2e4.ru left intact <?xml version="1.0" encoding="UTF-8"?><ListAllMyBucketsResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/"><Owner><ID>anonymous</ID><DisplayName></DisplayName></Owner><Buckets></Buckets></ListAllMyBucketsResult> real 0m30.138s user 0m0.020s sys 0m0.019s
Updated by Abhishek Lekshmanan over 4 years ago
Konstantin Shalygin wrote:
Sorry for long reply, perhaps missed notification.
I debugged deeper. The problem actually is why Civetweb waiting 30 seconds before send TCP FIN.
Usually HTTP/1.1 connections do keep-alive unless the client explicitly adds a connection:close header. so the socket isn't closed until this timeout.
Compared with nginx:
on setting 80r, basically 302 is sent asking the client to redirect to the ssl port. Was an ssl certificate set correctly with the ssl_certificate option?
Yes. Look at total time.
[...]
Updated by Konstantin Shalygin over 1 year ago
- Status changed from Need More Info to Won't Fix
civetweb was changed to beast