mod_http_upload fails with hosts_alias when put_url uses an HTTP alias

Environment

• ejabberd version: latest release
• Erlang version: erl +V
• OS: Linux (Docker container)
• Installed from: official ejabberd Docker image
• Reverse proxy: Caddy
• XMPP client: Gajim 2.x

Configuration (only if needed)

The XMPP virtual host is example.com, while xmpp.example.com is configured as an HTTP alias:

hosts:
  - example.com

hosts_alias:
  xmpp.example.com: example.com

The HTTP listener exposes mod_http_upload:

listen:
  -
    request_handlers:
      "/upload": mod_http_upload
      "/http-bind": mod_bosh
      "/ws": ejabberd_http_ws
    port: 5443
    ip: "::"
    module: ejabberd_http
    tls: true

The module is configured for the example.com virtual host:

host_config:
  example.com:
    modules:
      mod_http_upload:
        put_url: "https://xmpp.@HOST@/upload"
        docroot: "/var/www/upload"

A reverse proxy forwards https://xmpp.example.com/upload to the ejabberd HTTP listener and preserves the original Host header.

Errors from error.log/crash.log

No crash occurs.

The relevant ejabberd warning is:

Cannot handle PUT request from <proxy-ip> for example.com:
Upload not configured for this host

The HTTP request successfully reaches ejabberd.

The reverse proxy confirms that the PUT is forwarded to ejabberd with the expected host:

method: PUT
host: xmpp.example.com
uri: /upload/<token>/<path>/example.jpg
upstream: ejabberd:5443
status: 404

The 404 is therefore generated by ejabberd rather than the reverse proxy.

Bug description

mod_http_upload does not correctly resolve the configured upload virtual host when hosts_alias is used for the HTTP endpoint.

The XMPP virtual host is:

example.com

and:

hosts_alias:
  xmpp.example.com: example.com

is configured so that HTTP requests to xmpp.example.com map to the example.com virtual host.

The upload slot is successfully generated by the XMPP client. The client then performs the expected XEP-0363 HTTP PUT request to:

https://xmpp.example.com/upload/<...>

The reverse proxy correctly forwards the request to ejabberd with:

Host: xmpp.example.com

However, mod_http_upload responds with:

Upload not configured for this host

and returns HTTP 404.

This happens even though mod_http_upload is explicitly configured for the example.com virtual host.

Expected behavior

Since:

hosts_alias:
  xmpp.example.com: example.com

maps xmpp.example.com to example.com, the HTTP PUT should be handled by the mod_http_upload configuration belonging to example.com.

The uploaded file should then be written to the configured docroot.

Actual behavior

The PUT reaches ejabberd successfully, but mod_http_upload reports:

Upload not configured for this host

and returns HTTP 404.

The file is never written.

Workaround

Changing:

put_url: "https://xmpp.@HOST@/upload"

to:

put_url: "https://@HOST@/upload"

makes the upload work.

In this configuration, @HOST@ expands to:

example.com

instead of the HTTP alias:

xmpp.example.com

Therefore the workaround causes the PUT request to use the actual ejabberd virtual host name rather than its HTTP alias.

The problem appears to be the interaction between hosts_alias and the virtual-host lookup performed by mod_http_upload.

Minimal reproduction

hosts:
  - example.com

hosts_alias:
  xmpp.example.com: example.com

host_config:
  example.com:
    modules:
      mod_http_upload:
        put_url: "https://xmpp.@HOST@/upload"
        docroot: "/var/www/upload"

listen:
  -
    port: 5443
    module: ejabberd_http
    tls: true
    request_handlers:
      "/upload": mod_http_upload

Reverse proxy:

https://xmpp.example.com/upload/*
        ↓
ejabberd HTTP listener

Expected:

PUT → mod_http_upload for example.com → file saved

Actual:

PUT → "Upload not configured for this host" → HTTP 404

Workaround:

put_url: "https://@HOST@/upload"

which generates the upload URL using the actual XMPP virtual host instead of the HTTP alias.

I believe this is a bug or missing host-alias handling in mod_http_upload: hosts_alias should allow the HTTP alias to resolve to the configured virtual host consistently throughout the HTTP upload request lifecycle.

Start at the mod_http_upload request handler and trace how the incoming Host value is matched against host_config and hosts_alias. Reproduce the PUT using the provided minimal configuration and verify that the alias selects example.com, the request returns success, and the file is written to the configured docroot.