panics and/or EOF errors during GetPrinters request about go-ipp HOT 8 CLOSED

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

from go-ipp.

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

from go-ipp.

@phin1x there was an occasion to look into ?

from go-ipp.

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

from go-ipp.

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

from go-ipp.

@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.

from go-ipp.

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.

from go-ipp.

fixed in 1.6.1

from go-ipp.