Files produced by ipptool --ippserver cannot be processed by ippserver

[KurtPfeifle]

Maybe I'm mistaken with this... but here I go.

---

What should happen

I'm writing up this issue under the assumption that the --ippserver parameter should work in the folllowing scenario (maybe I'm wrong -- please tell):

1. Run "ipptool --ippserver attr.txt ipp://someserver-or-printer/ipp/print get-printer-attributes.test"
2. Run "ippserver -v -C ." (where the previously generated attr.txt is located in the current, otherwise empty, directory)

The ippserver would use the attr.txt file to determine which properties for the "MyTest" printer it should emulate.

---

What really happens

Observations:

1. A process started with ippserver -v -p 22222 "FirstTest" starts without a problem, and produces ~264 lines of output. (I used this one to connect ipptool --ippserver attr.conf to.)

2. The process started with ippserver -v -p 22222 -C . seems to hang on startup:

   $> ippserver -vv -p 22222 -C .
   Using default data directory "/tmp/ippserver.13890".
   Using default spool directory "/tmp/ippserver.13890".
   Ignore Avahi state 2.
   Using default listeners for lenjessie2.fritz.box:22222.
   serverRun: 0 printers configured.
   serverRun: 2 listeners configured.
   
   [...... no more output ......]
   

   NOTE: I made sure that attr.conf contained a valid DeviceURI line (had to edit it in, the generated one didn't contain one...)

3. Then I start ipptool again to connect to the running ippserver process with get-printer-attributes.test.

   a) I see this in ipptool output:

   $>  ipptool -vvt ipp://lenjessie2.local.:22222/ipp/print get-printer-attributes.test
   get-printer-attributes.test:
       Get-Printer-Attributes:
           attributes-charset (charset) = utf-8
           attributes-natural-language (naturalLanguage) = en
           printer-uri (uri) = ipp://lenjessie2.local.:22222/ipp/print
       Get printer attributes using Get-Printer-Attributes                  [FAIL]
           RECEIVED: 0 bytes in response
           status-code = server-error-service-unavailable (Operation now in progress)
           IPP request failed with status server-error-service-unavailable (Operation now in progress)
   $>
   

   b) The following happens then immediately for ippserver:

   [....]
   serverRun: 0 printers configured.
   serverRun: 2 listeners configured.
   serverRun: Incoming connection on listener lenjessie2.fritz.box:22222.
   [Client 1] Accepted connection from "192.168.76.34".
   Cleaning old jobs.
   [Client 1] POST /ipp/print
   [Client 1] Continue
   [Client 1] Request: version=1.1
   [Client 1] Request: operation-id=Get-Printer-Attributes(000b)
   [Client 1] Request: request-id=100971
   [Client 1] Request: operation-attributes-tag
   [Client 1] Request: attributes-charset (charset) utf-8
   [Client 1] Request: attributes-natural-language (naturalLanguage) en
   [Client 1] Request: printer-uri (uri) ipp://lenjessie2.local.:22222/ipp/print
   Segmentation fault
   

4. In general, the behaviour is not necessarily predictable. A few times, when "valid" printer .conf files are in the config directory alongside with one that --ippserver generated, I also see ippserver startup messages like these:

   Loading printer from "foo2.conf".
   Unknown directive "," on line 16 of "/home/kp/svn-stuff/git.kp-ippsample/test/print/foo2.conf".
   Loading printer from "bar2.conf".
   Unknown directive "," on line 3 of "/home/kp/svn-stuff/git.kp-ippsample/test/print/bar2.conf".
   

   Investigating these .conf files showed:

   1. line 16 of foo2.conf: ATTR keyword media-ready "na_letter_8.5x11in","iso_a4_210x297mm"

   2. line 3 of bar2.conf: ATTR charset charset-supported "us-ascii","utf-8"

      When I edit these lines to remove the quotes (not the commas), the same "Unknown directive" appears in ippserver's output, but for lines 4+17 now, which also have quoted values separated by commas...

[KurtPfeifle]

For the record: I first noticed this when using my AppImage package of IPP Sample (see comment at issue #60). After that I verified this with "traditionally" compiled versions of ippserver and ipptool.

[michaelrsweet]

Will investigate, but the configuration directive support expects a system.conf file in the root directory and per-printer configuration files in the "print" subdirectory (for regular printers) or "print3d" subdirectory (for 3D printers).

[michaelrsweet]

OK, it looks like the old attribute parser and the new token parser are mismatched. Going to investigate putting together a common parser interface/mini-library for ipptool and ippserver so that this issue is resolved and future incompatibilities are avoided.

[michaelrsweet]

Working on a common base parser:

[master fd96ad89f] Add (ASCII) IPP data file parser to libcups, to be used by ippserver and ipptool.

[michaelrsweet]

Finished the changes to ipptool:

[master 8e2e09c1e] Finish re-tooling of ipptool to use new parser.

Will merge those over here and then work on adopting for ippserver...

[michaelrsweet]

[master 3784fb9] Use new IPP file parser in ippserver (Issue #67)