osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug 53218] ProxyPass worker name (http://localhost:3128/...) too long


https://bz.apache.org/bugzilla/show_bug.cgi?id=53218

Christopher Schultz <chris@xxxxxxxxxxxxxxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |FIXED

--- Comment #26 from Christopher Schultz <chris@xxxxxxxxxxxxxxxxxxxxxx> ---
(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?

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: bugs-help@xxxxxxxxxxxxxxxx