Printing

Does Airprint use port 631?

My son has opened up port 631 on his Epson printer, specifically to my IP address. It shows some interesting things:

The printer has a setting for “Top Priority Protocol”, which can either be IPP or Port9100. Epson’s specification for it does not claim that it supports IPP!

Rick’s “FindIPP” works, but the response is “426 Upgrade required”, i.e. upgrade to https. So I can’t go any further on that – I’ll have to write my own more specific app.

By pointing a browser at port 631, I can see the printer’s home page. In fact I can see the Advanced settings too. IPP is very definitely there.

the response is “426 Upgrade required”

That’s not IPP, that’s IPPS. ;)

By pointing a browser at port 631, I can see the printer’s home page.

There may be a specific URL for print jobs to be sent to, and this depends upon the printer.

The HP inkjet is:

printer-uri = "ipp://192.168.1.14/ipp/print"
(continued) "ipps://192.168.1.14:443/ipp/print"

And the laser is:

printer-uri = "ipp://192.168.1.17:631/ipp/print"

Notice the laser uses port 631 and doesn’t support encryption. The inkjet uses ports 80 (unencrypted) and 443 (encrypted), not using port 631.

This is part of the discovery, and part of what my FindIPP stuff tries to extract from the printer.

Would you like to upgrade your FindIPP to secure?

That’s not IPP, that’s IPPS. ;)

I’m sure that’s how a lot of it will be. Secure communication has an easy general solution, so why wouldn’t we?

has an easy general solution

Which is…? The AcornSSL module? That would certainly work as a back end, but it’ll be a little more complicated than using the URL fetcher. At least, until somebody forks the AcornHTTP code and teaches it to speak IPP (which is similar but not the same).

Which is…? The AcornSSL module?

Yes.

At least, until somebody forks the AcornHTTP code and teaches it to speak IPP (which is similar but not the same).

Agreed. Also HTTP 1.1 – it would be nice to get that implemented just before everyone abandons it in favour of the next version…

The “426 Upgrade” message I saw yesterday listed both TLS and HTTP/1.1

I’ve dropped the source to FindIPP and SammyPrint (similarities) to http://heyrick.ddns.net/files/ippstuff.zip

Note that it was “some rubbish thrown together to see if it works”, but might be a basis to get started with ¹.

¹ I believe “with which to get started” may be more correct, but it just sounds pretentious.

Thanks, Rick! Something to get my teeth into.

At least, until somebody forks the AcornHTTP code and teaches it to speak IPP (which is similar but not the same).

Agreed. Also HTTP 1.1 – it would be nice to get that implemented just before everyone abandons it in favour of the next version…

Which aspects of HTTP 1.1 are you looking for particularly? AcornHTTP supports chunked transfers (which are a 1.1 thing) but I am guessing you are interested in persistent connections? Byte-range transfers might also be useful but the URL_Fetcher interface would need rewriting for that.

I’ve been thinking a bit about how the URL_Fetcher system might be rewritten to allow cookie handling to be kept application-specific, so it would be good to plan for fuller HTTP/1.1 support also.

If there’s enough in common between HTTP and IPP, they could be supported through the same module. AcornHTTP already registers itself twice with URL_Fetcher, to support http and https.

Which aspects of HTTP 1.1 are you looking for particularly?

One elementary thing is to send HTTP/1.1 instead of HTTP/1.0 – as simple as that. But choice of persistent transfers or not also seems useful.

And, yes, supporting ipp and ipps could save a lot of work. I don’t yet know how different the behaviours of http(s) and ipp(s) are. Maybe not at all. But it’s interesting that the responses from a printer’s port 631 via http and ipp are different. The parsers know which sort of information is being requested.

The Wikipedia page on IPP seems to suggest that the protocol is HTTP, so IPP may just be a matter of how you use the endpoint, i.e. what the URLs look like and what the responses contain.

I tried connecting to my own printer on http://192.168.1.66:631/ using Firefox on a Linux laptop, and it just redirected me straight away to its web interface on http://192.168.1.66:80/ but perhaps it was able to do that because I had not put any IPP-specific paths in the URL?

It didn’t help that I was unable to find, in the brief time I allowed myself to be distracted by this, any descriptions of IPP at the protocol level that might have enabled me to construct a real request.

I might experiment with changing HTTP/1.0 to HTTP/1.1 and see what happens. It may only state HTTP/1.0 to maximise compatibility with older web-servers, which may have been a consideration when AcornHTTP was first developed! I suppose the worry is if there is anything in 1.1 which AcornHTTP does not support. It does support chunked transfers, which I think are the main concern. It doesn’t support sending more requests via the same socket during the processing of the incoming request, but as that’s a client-side choice, it would not be a problem.

I suppose by sending 1.0 rather than 1.1, some servers will be avoiding using compression and chunked transfers because they think the client cannot cope with them. That might explain why I am getting 2MB of uncompressed XML from an API, which seems very inefficient!

seems to suggest that the protocol is HTTP, so IPP may just be a matter of

It is essentially HTTP with a binary payload. The problem is that by using URL/AcornHTTP there is an opaque layer between what the client requests and what is actually sent, that could muck things up. It does try to be sensible, however.

Edit: Deleted some stuff.
I fell into the trap of “complain that something isn’t working on a forum, find a solution twenty minutes later”.
Gah. I spent days scratching my head over that. :-/

but perhaps it was able to do that because I had not put any IPP-specific paths in the URL?

Correct. That’s something that my FindIPP extracts from the printer. It’s a part of the “discovery” process that happens when a new printer is found. Sadly, it seems that different printers use different URIs, though I seem to be able to read status by sending a POST request to /ipp/print on port 631.

any descriptions of IPP at the protocol level that might have enabled me to construct a real request.

You probably did, but didn’t realise it. Ten seconds of Googling will point you at the IPP docs at pwg.org, and various RFCs (3510 for IPP, 7472 for IPPS) which describe it all in detail.

But the part you might have missed (I did on a first read) is that it’s a binary protocol and it uses the format of a tag byte followed by a key followed by appropriate data.

For example, requesting the attributes of a device, I send:

short    &0101                 - version 1.1
short    &0008                 - get attribute
word     1                     - request ID
byte     1                     - operation attributes
byte     &47                   - charset tag
string   "attributes-charset"  - identifier
string   "utf-8"               - value
byte     &48
string   "attributes-natural-language"
string   "en-us"
byte     &45
string   "printer-uri"
string   "ipp://192.168.1.14:631/ipp/print"
byte     &44
string   "requested-attributes"
string   "all"
byte     3                     - end of request

Post that to /ipp/print (assuming it’s device 192.168.1.14) with the content-type application/ipp and you should get between 2 and 14 kilobytes in response containing as much information as the printer deigns to send, all of it laid out in a fairly similar format.

Refer to the previously-linked archive for the source to my FindIPP that does this.

I might experiment with changing HTTP/1.0 to HTTP/1.1 and see what happens.

I send HTTP 1.1 requests, as that’s what – IIRC – the docs use in their examples.

That might explain why I am getting 2MB of uncompressed XML from an API, which seems very inefficient!

Welcome to the internet in the 2020s. If you look at what some sites are doing under the hood, it’s quite unpleasant and extremely wasteful. But since “everybody has broadband and mobile comms is dirt cheap”, it is only getting worse.

2MB of data isn’t really that different to loading an entire JavaScript framework (like JQuery) in order to make use of one three line function. :-/

If you have Firefox on a desktop machine, go to the tools, developer stuff, and call up the network thingy. This will open a pane on the lower third of Firefox’s window to list all of the fetches, how long they take, and what’s actually being requested. You can examine full headers and payloads, in both directions.
Prepare to be horrified by what some sites get up to.

Prepare to be horrified by what some sites get up to

Including bone idle “look I’m coding” web “authors” pulling mega code blocks¹ from all over the net just for those “three line function” elements.

Seeing work done on print systems is interesting, especially from my current view: I can’t recall the last time I printed out a hard copy of anything² topped off by a “leaving card envelope” doing the rounds in the office:

1. 90% of the department isn’t on site (even weekly)
2. Contactless payments means that virtually no one has any money on them
3. It took 5 minutes to find a pen for anyone to sign the card

¹ Including the nasty, nasty habit of using images that fill a screen and then scaled to be small buttons using CSS.
With a bit of effort and some intelligent thought, most of the websites you see each day could be blindingly fast

If there’s enough in common between HTTP and IPP, they could be supported through the same module. AcornHTTP already registers itself twice with URL_Fetcher, to support http and https.

Matthew, I have two suggestions:

First is that, if you’d like to create a test build of AcornHTTP that claims to support ipp and ipps, I would be very happy to give it some exercise over the coming weeks, and feed back my findings to you. This can’t possibly count as a formal test since I’m learning (from scratch) as I go.

Second is a more general one. I don’t see a problem with experimental ipp/ipps support going out in builds of AcornHTTP that might be coming out in the near future and would be available from the ROOL download site, because I cannot see any way in which ipp/ipps can be invoked accidentally – it would have to be a deliberate action by somebody – and the module would not claim to support it unless and until support had been tested and found satisfactory. What do others think?

What do others think?

Isn’t this what the non-stable versions are for? Testing stuff?

and the module would not claim to support it unless and until support had been tested and found satisfactory.

I don’t think there’s any reason not to have it available. Nothing is going to be using ipp: or ipps: protocols except for the software currently being discussed, so it isn’t going to interfere with existing use.
Until everything is ready, it’ll just be another entry or two in the *URLProtoShow command that few people ever enter…

Count me in for testing too, if you like.

I have a Samsung MW-2022 laser that supports AirPrint but not IPP (too old), which uses URF style image bitmaps; I can also use this from RISC OS by throwing LJ6 PCL data at it.

My other printer is on HP 3630 inkjet which doesn’t currently work from RISC OS (though I’ve not yet tried the IPP stuff mentioned here). I am a subscriber to HP Instant Ink, so a few messed up pages (all I ever got!) won’t be the end of the world. Supports AirPrint and IPP.

Hmm… I think I have some sort of Epson inkjet as well. Will support one or both. Not sure, it’s still in its box. I got it as it was cheaper than refill inks for the old Canon, but then got the HP for the Instant Ink and never made it as far as unboxing the Epson!

Count me in for testing too, if you like.

And me.

I have a HP254DW which is Airprint 1.6 and the 3637 Airprint 1.4 and ipp-everywhere

I have used Chris Gransden’s IIPTools to print to both.

I also have a HP B110 printer as well to test to is it helps.

Rick your Hp3630 should work with IIPTools sending a Jpeg but not a PDF.

Update. Should of said they are IPP capable as well.

First is that, if you’d like to create a test build of AcornHTTP that claims to support ipp and ipps, I would be very happy to give it some exercise over the coming weeks, and feed back my findings to you. This can’t possibly count as a formal test since I’m learning (from scratch) as I go.

I’ve had a look at Rick’s FindIPP source to see what it does, and I don’t think that AcornHTTP needs modifying at all. The protocol used for IPP appears to be pure HTTP. The query Rick is sending is sent via POST to /ipp/print with a Content-Type of application/ipp.

You should be able to call URL_GetURL with:

• R0=2 (optionally set bit 1 to supply your own user agent string in R6, and set bit 30 to prevent AcornHTTP adding any cookies)
• R1=session id
• R2=4 (POST)
• R3 = “https://my.printer:631/ipp/print” or http if you prefer.
• R4 = pointer to data block
• R5 = length of data block
• R6 (optionally, pointer to user agent string)

R4 would be a pointer to a block containing:

• “Content-Type: application/ipp” + CR + LF
• “Content-Length: " + (byte length of payload in decimal) + CR + LF
• CR+LF
• The binary payload for IPP

The AcornHTTP module will add the Host header. Then you would be in a position identical to Rick’s FindIPP source.

The only issue will be if the printer refuses to respond to an HTTP/1.0 request, but I would be surprised if that were an issue. It would be easy to build an experimental module with the outgoing request line changed.

If that’s the case, it just means rejigging it to use the URL fetcher, and if so we’ll have TLS support for free. Nice.

The only advantage I can see to having an IPP fetcher module is that perhaps the Content-Type and Content-Length headers could be written automatically, and the client could just supply the binary portion. Similarly it could return just the binary body, and not the headers. Depends on whether you need to react to stuff in the headers, of course.

I eventually realised that I was wanting to use the URL fetcher rather than AAcornHTTP. It’s the formet that would require modification to support IPP/IPPS. But if it did that, then IPP/IPPS communication would become really easy.

I see it looks at Inet$EtherIPAddr which only works if that’s a dotted-quad value. Mine’s “RasPi3B” because the IP address is “from hostname”.

I have another program that I’m working on right now that tries to parse Inet$EtherIPAddr in order to determine the base IP address (in other words, 192.168.1.10 → 192.168.1.x).

So this question raises it’s head again. Why is a system variable called “IPAddr” allowed to be set to something that isn’t an IP address?

I know you can assume it’s a hostname if it isn’t an IP address and resolve that, but really this is not something that the apps should be concerning themselves with. It declares itself as an IP address, that’s what it should be. The lookup should be done once as the stack starts up, not some half-assed cop-out of putting the hostname in there. There’s already Inet$Hostname.

:-/

I eventually realised that I was wanting to use the URL fetcher rather than AcornHTTP. It’s the format that would require modification to support IPP/IPPS. But if it did that, then IPP/IPPS communication would become really easy.

Yes, when I was talking about modifying AcornHTTP above, it was not with a view to it being used directly, but through the URL Fetcher module. I don’t think anything needs altering in either module, but perhaps I am missing something?

I’m not sure I understand what you mean about the format.

I know you can assume it’s a hostname if it isn’t an IP address and resolve that,

ping 3232236099 :)