On 02/07/2018 07:45 PM, Graham Leggett wrote:
> On 07 Feb 2018, at 8:36 PM, William A Rowe Jr <wr...@rowe-clan.net 
> <mailto:wr...@rowe-clan.net>> wrote:
>> But there is no argument for a name identifier >255 characters ... the cited 
>> RFC
>> and the filesystem and so many others use this as the conventional constraint
>> on an identifier.
>> Why double that?
> Because the part of the URL that matters to the admin might be at the end, as 
> in Dirk’s example. If we’ve consumed the
> whole length on the hostname, we leave nothing for the URL itself.
> Eg: https://very-very-long-hostname/foo/bar/baz/veryimportant1 and
> https://very-very-long-hostname/foo/bar/baz/veryimportant2
> The burning question is - are these fields only used for debugging, and 
> therefore an approximation is fine, or are they
> used for something else where precision is required?

IMHO they are used by mod_proxy_hcheck to set a host header for the "check" 
request and for getting the IP of the
backend. So truncating does not seem to be an option unless fixed there. But 
even if we fix mod_proxy_hcheck, what makes
us sure that other 3rd party modules do not do the same?

There is a comment in mod_proxy.h of 2.4.x that says:

"The addition of member uds_path in 2.4.7 was an incompatible API change. "

Increasing the length of the fields in proxy_worker_shared would IMHO be 
incompatible as well since proxy_worker_shared
is in mod_proxy.h and hence part of the public API.

So I think neither truncating nor increasing the field size is backportable.



Reply via email to