Richard Hansen

@pini-gh It sounds like you are proposing support for different container ports for different `location` blocks, but all virtual hosts are configured identically. I think this bug is originally about...

> But the main problem people express in this thread is dealing with containers exposing more than one port as you can see in these quotes: I agree that there's...

> For virtual hosts defined with a dedicated port (say `app.example.com:1234`), the variable `VIRTUAL_PORT` is ignored To make sure I understand your proposal, you're saying that any `VIRTUAL_HOST` without a...

How would you express this example: > * `https://foo.example/a/` proxies to `http://app:80/xyz/` > * `https://foo.example/b/` proxies to `http://app:81/b/` > * `https://bar.example/a/` proxies to `https://app:443/` > * `https://bar.example/b/` proxies to `https://app:444/`...

What's the downside to the syntax I proposed in https://github.com/nginx-proxy/nginx-proxy/issues/1504#issuecomment-1379464211? Here is an attempt at formalizing it ([ABNF](https://www.rfc-editor.org/rfc/rfc5234), with `host`, `reg-name`, `port`, and `path` as defined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986) and...

> I don't know. I just did differently and I like my solution because it is backward compatible with current nginx-proxy version. I don't think any PR breaking backward compatibility...

Heh, #259 is almost identical to what I propose, just simplified.

> At that point, you could leave `VIRTUAL_HOST` as it is and introduce a new `VIRTUAL_HOST_JSON_CONFIG` or similar? Given that we want to move to labels (#2148), we could leave...

@VincentSC > I looked into labels and I'm not sure this will be an easy introduction. I'd suggest to leave that problem out, to avoid delaying this feature. Labels are...

I'm having trouble parsing the proposed syntax. Can you express it in ABNF? Also, see [my comment in #1504](https://github.com/nginx-proxy/nginx-proxy/issues/1504#issuecomment-1379464211).