Connection problems since ureq update

[Phaiax]

Hi

I noticed that the current version of ipp.rs does not support my printer anymore.

Some issue was introduced when updating the ureq and/or tls depencency.

A minimal example program that does get_attributes returns this with commit 2daaeec and until current master

Attributes:
Ok(
    IppAttributes {
        groups: [
            IppAttributeGroup {
                tag: OperationAttributes,
                attributes: {
                    "status-message": IppAttribute {
                        name: "status-message",
                        value: TextWithoutLanguage(
                            "Bad request version number!",
                        ),
                    },
                    "attributes-charset": IppAttribute {
                        name: "attributes-charset",
                        value: Charset(
                            "utf-8",
                        ),
                    },
                    "attributes-natural-language": IppAttribute {
                        name: "attributes-natural-language",
                        value: NaturalLanguage(
                            "en-us",
                        ),
                    },
                },
            },
        ],
    },
)

and this with commit 60677dd

Attributes:
Ok(
    IppAttributes {
        groups: [
            IppAttributeGroup {
                tag: OperationAttributes,
                attributes: {
                    "attributes-natural-language": IppAttribute {
                        name: "attributes-natural-language",
                        value: NaturalLanguage(
                            "en-us",
                        ),
                    },
                    "attributes-charset": IppAttribute {
                        name: "attributes-charset",
                        value: Charset(
                            "utf-8",
                        ),
                    },
                },
            },
            IppAttributeGroup {
                tag: PrinterAttributes,
                attributes: {
                    "natural-language-configured": IppAttribute {
                        name: "natural-language-configured",
                        value: NaturalLanguage(
                            "en-us",
                        ),
                    },
                    "urf-supported": IppAttribute {
                        name: "urf-supported",
                        value: Array(
                            [
                                Keyword(
                                    "W8",
                                ),
                                Keyword(
                                    "SRGB24",
                                ),
                                Keyword(
                                    "V1.5",
                                ),
                                Keyword(
                                    "RS300",
                                ),
                                Keyword(
                                    "IS7",
                                ),
... many more lines of attribute information

The status-message Bad request version number! could mean something is off with the TLS connection, but why does it even respond?

The printer url is ipp://SELPHY-DHCP-INSTANCE-0.fritz.box/ipp/print so its not a TLS connection.

Do you have any idea?

[ancwrd1]

I think it is most likely some HTTP header which printer refuses to accept. Could you compare which headers are sent in both cases? E.g. via wireshark.

[ancwrd1]

Could be also HTTP 2.0 vs HTTP 1.1, I will check it and try to reproduce.

[Phaiax]

This is what wireshark sees in the TCP payload of the first request. The following IPP payload is equal. The immediate answer already to the request differs in the Content-Length in line with the above responses.

Working version:

"POST /ipp/print HTTP/1.1\x0d\x0aHost: selphy-dhcp-instance-0.fritz.box:631\x0d\x0aUser-Agent: ipp/5.2.0;ureq\x0d\x0aAccept: */*\x0d\x0acontent-type: application/ipp\x0d\x0aTransfer-Encoding: chunked\x0d\x0a\x0d\x0a"

Not working version:

"POST /ipp/print HTTP/1.1\x0d\x0atransfer-encoding: chunked\x0d\x0auser-agent: ipp/5.4.0;ureq\x0d\x0aaccept: */*\x0d\x0ahost: SELPHY-DHCP-INSTANCE-0.fritz.box:631\x0d\x0acontent-type: application/ipp\x0d\x0a\x0d\x0a"

[Phaiax]

Formatted:

Working:

POST /ipp/print HTTP/1.1
Host: selphy-dhcp-instance-0.fritz.box:631
User-Agent: ipp/5.2.0;ureq
Accept: */*
content-type: application/ipp
Transfer-Encoding: chunked

Non Working:

POST /ipp/print HTTP/1.1
transfer-encoding: chunked
user-agent: ipp/5.4.0;ureq
accept: */*
host: SELPHY-DHCP-INSTANCE-0.fritz.box:631
content-type: application/ipp

[Phaiax]

algesten/ureq#963

[Phaiax]

Its only the transfer-encoding where the printer has an issue. So its a printer bug :/

See the response size which is 6558 vs 121.

curl -v -H "content-type: application/ipp" -H "host: SELPHY-DHCP-INSTANCE-0.fritz.box:631" -H "user-agent: ipp/5.4.0;ureq" -H "accept: */*" -H "Transfer-Encoding: chunked" http://SELPHY-DHCP-INSTANCE-0.fritz.box:631/ipp/print --data-binary @gar -o - | wc -c

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Host SELPHY-DHCP-INSTANCE-0.fritz.box:631 was resolved.
* IPv6: (none)
* IPv4: 192.168.213.42
*   Trying 192.168.213.42:631...
* Connected to SELPHY-DHCP-INSTANCE-0.fritz.box (192.168.213.42) port 631
> POST /ipp/print HTTP/1.1
> Host: SELPHY-DHCP-INSTANCE-0.fritz.box:631
> content-type: application/ipp
> user-agent: ipp/5.4.0;ureq
> accept: */*
> Transfer-Encoding: chunked
> 
} [147 bytes data]
< HTTP/1.1 200 OK
< Content-Type: application/ipp
< Content-Length: 6558
< 
{ [1460 bytes data]
100  6694  100  6558  108   147  88740   1989 --:--:-- --:--:-- --:--:-- 91849
* Connection #0 to host SELPHY-DHCP-INSTANCE-0.fritz.box left intact
6558

curl -v -H "content-type: application/ipp" -H "host: SELPHY-DHCP-INSTANCE-0.fritz.box:631" -H "user-agent: ipp/5.4.0;ureq" -H "accept: */*" -H "transfer-encoding: chunked" http://SELPHY-DHCP-INSTANCE-0.fritz.box:631/ipp/print --data-binary @gar -o - | wc -c

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Host SELPHY-DHCP-INSTANCE-0.fritz.box:631 was resolved.
* IPv6: (none)
* IPv4: 192.168.213.42
*   Trying 192.168.213.42:631...
* Connected to SELPHY-DHCP-INSTANCE-0.fritz.box (192.168.213.42) port 631
> POST /ipp/print HTTP/1.1
> Host: SELPHY-DHCP-INSTANCE-0.fritz.box:631
> content-type: application/ipp
> user-agent: ipp/5.4.0;ureq
> accept: */*
> transfer-encoding: chunked
> 
} [147 bytes data]
< HTTP/1.1 200 OK
< Content-Type: application/ipp
< Content-Length: 121
< 
{ [121 bytes data]
104   257  100   121  108   147   2104   2556 --:--:-- --:--:-- --:--:--  4701
* Connection #0 to host SELPHY-DHCP-INSTANCE-0.fritz.box left intact
121

[ancwrd1]

I have seen similar issues with older Xerox printers which have a buggy chunked-encoding implementation. I guess I can introduce a new variant of IppPayload of Vec<u8> or Bytes type, so it will be sent unchunked.

[ancwrd1]

You could also use ipp.rs to encode the request into byte array and send it using ureq without chunked encoding.