panics and/or EOF errors during GetPrinters request

[kruftik]

(possibly connected with #29)

Present implementation of the http-based adapter has a strange behaviour with a partial or erroneous get printer list response. The GetPrinters request return only a part of the entire printers list or panics with "makeslice: len out of range" / completes with an EOF error. The source of the issue seems to be at AttributeDecoder#decodeString method where the number of read bytes is ignored but sometimes the actual number of read bytes is less than the provided slice length.

There is a possible work-around - read entire CUPS response into a []byte slice and to ResponseDecoder.Decode() not the original http.Response.Body but the bytes.NewReader of the slice.

The behaviour can be reproduced with: https://github.com/kruftik/go-ipp-panics-repro

[phin1x]

Hi @kruftik, thank you for the good error description. i will have a look into it at the weekend

[kruftik]

@phin1x there was an occasion to look into ?

[anirudhagarwal1]

@kruftik Can you explain in details the work around that you mentioned?

[anirudhagarwal1]

@phin1x Did you get a chance to check out this issue?

[kruftik]

@kruftik Can you explain in details the work around that you mentioned?

actually, I didn't dive into deep details. I have noticed that the response buffering before parsing prevents strange panics and that's it :-)

my suppose there is some kind of "batching" during response writing from CUPS side and/or reading inside the stdlib and such a batching causes slice out-of-bounds panics since the library expects contant offsets / sizes etc.

[phin1x]

i have updated the http adatper to preload the ipp response into a buffer (the socket adapter already does this). i initially tried to avoid loading the entire ipp response into memory, as ipp responses can contain additional data (e.g. spool files or configs) which can be several gigabytes in size.

please try the master branch and let me know if the problem is fixed.

some notes on strings in the ipp protocol. strings are encoded by first specifying the length with an int16 and then the actual string content. we decode this by reading the size, creating a fixed byte-slice with the size read, and reading from the reader with the byte slice. this way the reader is always forwarded by the correct amount. potential padding is discarded by converting from a byte-slice to a string.

[jameshalsall]

I had a similar issue when getting printer attributes (ipp.OperationGetPrinterAttributes) - I would see EOF errors intermittently

@phin1x your latest changes fixed the problem for me 👍🏻 thanks

[phin1x]

fixed in 1.6.1