Bug#952894: cups: Bad Request for FQDN without explicit ServerAlias
On Mon, 2020-03-02 at 08:48 +0100, Didier 'OdyX' Raboud wrote:
> Le dimanche, 1 mars 2020, 16.43:56 h CET Kevin Locke a écrit :
>> Accessing CUPS via https://hostname:631 works while
>> https://hostname.example.com:631 fails with 400 Bad Request if
>> cupsd.conf does not contain either "HostNameLookups on" or
>> "ServerAlias printserver.example.com". This is a divergence from
>> upstream, where the FQDN returned by gethostname(2) is automatically
>> added as a ServerAlias.
One additional caveat: CUPS accepts FQDN with .local TLD as a special
case, with or without the patch.
>> It appears to be an untended side-effect of
>> 0026-Do-not-use-host-names-for-broadcasting-print-queues-.patch for
>> LP#449586. Perhaps we could consider a different way to disable name
>> broadcasting without removing the ServerAlias for the FQDN which is used
>> for HTTP host checking?
>
> Have you tried building and testing without this patch?
I hadn't, but did just now. I can confirm CUPS now responds 200 OK to
requests with FQDN Host. However, I'm not familiar with mDNS and
don't have cups-browsed installed, so I can't confirm whether the
patch would cause the FQDN to be broadcast and what effects that might
have, as in LP#449586.
> After 4+ years, it seems realistic to try without this patch again but: a)
> only if we're sure it helps, b) only after 2.3.1-11 is migrated to testing.
I don't feel qualified to weigh the trade-off between requiring
explicit ServerAlias for valid FQDN and causing mDNS issues due to
invalid FQDN. At least the current behavior was relatively easy to
debug. Feel free to hold off until someone with mDNS experience, or
with a stronger rationale for either side weighs in.
Thanks,
Kevin
Reply to: