`mime.types` matching buffer limitation to 4096 bytes not documented / not shown in error output

[olifre]

Describe the bug
The manpage mime.types.5 does not mention the limitation of the matching buffer, e.g. for the contains operation. Matching is currently limited to 4096.
If higher lengths are used, matching seems to be silently limited to the first 4096 characters following the offset.

To Reproduce
Steps to reproduce the behavior:

1. Add a mime.types dropin using contains(0,8000,"LANGUAGE=PCL").
2. Test it out on a sample document, e.g. the one from PCL print jobs mistakenly detected as "ASCII" instead of application/vnd.cups-raw if header is too long #924 , with cupsfilter.
3. Observe it does not match byeond 4096 chars.

Expected behavior
An error should be shown, or the limitation should be documented (or both).

Additional context
Limitation is hardcoded in the code here:

cups/scheduler/mime.h

Line 32 in 9383b37

# define MIME_MAX_BUFFER 4096 // Maximum size of file buffer

Of course a limit is very reasonable (#924 shows that is may be too small for nowadays print jobs in some cases to cover everything in a single match, though). It would be nice if this limit was documented or exceeding it would produce a warning (or both).

[michaelrsweet]

Producing a warning is possible but documenting it is probably the best approach at this point since all of the MIME code will be gone in CUPS 3.0...

[michaelrsweet]

Marked #924 as a dupe of this; investigate increasing the limit (if possible) or updating the default PCL/PS detection rules to allow for outrageously long PJL headers from Windows clients.

[michaelrsweet]

[master 55e9513] Increase the mime.types limit to 8192 bytes and document it (Issue #925)

[olifre]

Many thanks, both for the bump and for documenting the new limit! 👍