Bug #23489

[rgw] civetweb behind haproxy doesn't work with absolute URI

Added by Aleksandr Rudenko almost 2 years ago. Updated 11 months ago.

In Progress
Target version:
% Done:


Community (user)
3 - minor
Affected Versions:
Pull request ID:
Crash signature:


I'm sorry, maybe it isn't bug, but i don't know how to solve this problem.

I know that absolute URIs are supported in civetweb and it works fine for me without haproxy in the middle.

But if client send absolute URIs through reverse proxy(haproxy) to civetweb, civetweb breaks connection without responce.

i set:

debug rgw = 20
debug civetweb = 10

but no any messgaes in civetweb logs(access, error) and in rgw logs.
in tcpdump i only see as rgw closes connection after request with absolute URI. Relative URIs in requests work fine with haproxy.

Docker registry v2.6.2, s3 driver based on aws-sdk-go/1.2.4 (go1.7.6; linux; amd64) uses absolute URI in requests.

s3 driver options of docker registry:

    region: us-east-1
    bucket: docker
    accesskey: 'access_key'
    secretkey: 'secret_key'
    secure: false
    v4auth: true

ceph.conf for rgw instance:

    rgw dns name =
    rgw enable apis = s3, admin
    rgw dynamic resharding = false
    rgw enable usage log = true
    rgw num rados handles = 8
    rgw thread pool size = 256

    host = aj15
    keyring = /var/lib/ceph/radosgw/rgw.a.keyring
    rgw enable static website = true
    rgw frontends = civetweb num_threads=128 port= access_log_file=/var/log/ceph/civetweb.rgw.access.log error_log_file=/var/log/ceph/civetweb.rgw.error.log
    debug rgw = 20
    debug civetweb = 10

very simple haproxy.cfg:

    chroot /var/empty
    # /log is chroot path
    log /haproxy-log local2

    pidfile /var/run/

    user haproxy
    group haproxy

    ssl-default-bind-options no-sslv3
    ssl-dh-param-file /etc/pki/tls/dhparams.pem

    mode http
    log global

frontend s3

    bind *:80
    bind *:443 ssl crt /etc/pki/tls/certs/s3.pem crt /etc/pki/tls/certs/s3-buckets.pem

    use_backend rgw

backend rgw

    balance roundrobin

    server a aj15:7480 check fall 1
    server a aj16:7480 check fall 1

http haeder from tcpdump before and after haproxy:

User-Agent: aws-sdk-go/1.2.4 (go1.7.6; linux; amd64)
Authorization: AWS4-HMAC-SHA256 Credential=user:/20180328/us-east-1/s3/aws4_request, SignedHeaders=host;x-amz-content-sha256;x-amz-date, Signature=10043867bbb2833d50f9fe16a6991436a5c328adc5042556ce1ddf1101ee2cb9
X-Amz-Content-Sha256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
X-Amz-Date: 20180328T111255Z
Accept-Encoding: gzip

i don't understand how use haproxy and absolute URIs in requests(


#1 Updated by Abhishek Lekshmanan almost 2 years ago

What happens when authentication_domain is not set in civetweb options? Since we disable authentication domain check in civetweb by default, passing this option may cause different behaviours

#2 Updated by Abhishek Lekshmanan almost 2 years ago

  • Status changed from New to Need More Info

#3 Updated by Abhishek Lekshmanan almost 2 years ago

  • Assignee set to Abhishek Lekshmanan

#4 Updated by Aleksandr Rudenko almost 2 years ago

I try without "authentication_domain=" but it's not helped.
I try without "rgw dns name"(rgw option) and the same.
I try many parameters but had no success.
Civetweb or rgw(i don't know) dropped tcp connection and i don't have any logs for debug(.

#5 Updated by Abhishek Lekshmanan almost 2 years ago

  • Status changed from Need More Info to In Progress

#6 Updated by Abhishek Lekshmanan over 1 year ago

When using absolute urls, following things need to be in order:

rgw_dns_name must correspond to the host part of url the client is requesting... so in this case the url used in the clinet must correspond to rgw dns name and this request much reach rgw as such. What happens without the haproxy? are the requests being honoured correctly?

#7 Updated by Aleksandr Rudenko over 1 year ago

Yes, you can see in issue description that rgw_dns_name corresponded to the host part of client url.

It's easy to reproduce. Steps:

# docker pull registry
cat /root/config.yaml
version: 0.1
    service: registry
    blobdescriptor: inmemory
    region: us-east-1
    bucket: docker
    accesskey: 'access_key'
    secretkey: 'secret_key'
    regionendpoint: http://your-s3-endpoint
    secure: false
    v4auth: true
    addr: :5000
        X-Content-Type-Options: [nosniff]
    enabled: true
    interval: 10s
    threshold: 3
# docker run --name registry --rm --network host -e DEBUG=true -v /root/config.yaml:/etc/docker/registry/config.yml registry:latest

in my custom haproxy logs i see:

haproxy[3743089]: [31/May/2018:10:21:31.599] s3 rgw/aj15 0/0/0/-1/0 502 204 - - SH-- 1/1/0/0/0 0/0 {|http|||aws-sdk-go/1.2.4 (go1.7.6; linux; amd64)} "GET HTTP/1.1" 

SH in haproxy log mean:

     SH   The server aborted before sending its full HTTP response headers, or
          it crashed while processing the request. Since a server aborting at
          this moment is very rare, it would be wise to inspect its logs to
          control whether it crashed and why. The logged request may indicate a
          small set of faulty requests, demonstrating bugs in the application.
          Sometimes this might also be caused by an IDS killing the connection
          between haproxy and the server.

it's realy true, i see full http header sended to rgw:

User-Agent: aws-sdk-go/1.2.4 (go1.7.6; linux; amd64)
Authorization: AWS4-HMAC-SHA256, SignedHeaders=host;x-amz-content-sha256;x-amz-date, Signature=df96ad46ea127f3b4e0815c92b9f865c910aff6b0bb844a9225b5fc7be4036bb
X-Amz-Content-Sha256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
X-Amz-Date: 20180531T071711Z
Accept-Encoding: gzip
X-Forwarded-Proto: http

and i see that rgw drop the connection without any logs.
As you can see header is correct.

#8 Updated by Dieter Roels over 1 year ago

should be fixed by this PR:

#9 Updated by Dieter Roels over 1 year ago

Sorry, I was under the impression this was on mimic but its luminous. AbsoluteURI and thus docker registry works on luminous starting from 12.2.2 up to at least 12.2.7 as thats what we use our ceph clusters for. Civetweb 1.10 broke this in 13.2, but there is a PR that will fix this, see

#10 Updated by Abhishek Lekshmanan 11 months ago

Yeah absolute urls should be fixed in 13.2.5

Also available in: Atom PDF