Comment 29 for bug 1964829

(In reply to Christopher Schultz from comment #26)
> (In reply to Ruediger Pluem from comment #25)
> > >
> > > (In reply to Jim Jagielski from comment #22)
> > > > Of course exposing resources unintentionally is EVIL. That is why when there
> > > > is the possibility, it is logged so allow the admin, who is the final
> > > > arbitrator, to determine if they are exposed or not.
> > >
> > > Unfortunately, the log is only advisory. httpd continues to start up in what
> > > I would describe generously as a "degraded" condition... one where a
> > > (likely) larger URL space will be proxied than initially intended.
> >
> > I would completely agree if this would be the case, but it isn't. The error
> > messages tells you that the worker name was truncated. This is unrelated to
> > the request URL that is forwarded. The truncated worker name only means that
> > if you have multiple ProxyPass directives and if the truncation of the
> > worker name leads to the same worker name they use the same connection pool
> > for the backend connections. This is no issue at all, contrawise: It saves
> > resources on the backend.
>
> Thanks for that clarification. To re-phrase, the worker name is being
> truncated, but incoming URLs will not be truncated for comparison, yes?

Correct.

>
> Could this become a problem is if the hostname of the origin server is
> something insanely long? For example, if I want two workers like
> http://super-long-hostname:80/ and http://super-long-hostname:81/ and those
> "super-long-hostname" names exceed the worker-name limit, they will be
> considered the same worker, yes? That means that requests that should go to
> e.g. port 81 might end up instead going to port 80.

Yes, this would be a problem. There is a similar PR (PR62085) on this.
But due to ABI constraints this is not easy to fix in a stable version.