The CLIENT (the thing that actually implements IPP) gets
"ipp://printer.company.com/prt32" as its target. The CLIENT
is wanting to print, so it creates some application/ipp stuff
that indicates the print job, and sends it to
"http://printer.company.com:380/prt32". If it is sending it
through a proxy, the proxy sees "http://printer.company.com:380/prt32".
Since the proxy only sees "http://printer.company.com:380/prt32",
I'm sorry that I've been less than totally clear on this, but it
seems so simple that it wouldn't have to require such a lengthy
explanation.
SCENARIO for client talking to "ipp://printer.company.com/prt32"
Step 1: Client creates "application/ipp" data.
Step 2: Client translates "ipp://printer.company.com/prt32"
to http URL by
Step 2a: changing scheme from "ipp" to "http"
Step 2b: adding port 380, if IPP URL doesn't contain a port
resulting in "http://printer.company.com:380/prt32"
Step 3: Client sends data created in Step 1 to URL created in step 2.
Step 3a: Request method: the request method is POST
Step 3b: Request URI:
if a proxy is in use:
Step 3b-proxy: the client's HTTP protocol stack
will use the entire "http://printer.company.com:380/prt32"
URL as the request-URI to the proxy.
if no proxy is in use:
Step 3b-noproxy: the client's HTTP protocol
stack will use "/prt32" as the request-URI
in a connection to "printer.company.com" on port 380
Step 3c: Host
The "Host" header should contain "printer.company.com:380"
corresponding to the HTTP host.
Step 3d: Content-Type
The content-type should be application/ipp
Step 4-proxy:
In the case a proxy is being used, this step occurs at the proxy.
The proxy receives a request constructed in Step 3, using the
request URI constructed in Step 3b-proxy. Note that this request
at the proxy appears as "http://printer.company.com:380/prt32".
Note that the string "ipp:" does not occur in the request URI.
Note that the "Host" header constructed in step 3c is matches the
host in the request-URI.
Step 4a: the proxy analyzes "http://printer.company.com:380/prt32"
and notes that it is a HTTP request to "printer.company.com" on port 380.
Step 4b: scheme dispatching
The proxy dispatches the request to the HTTP request handler,
since the scheme in the request URI is "http"
Step 4c: domain name filtering and forwarding
The proxy (potentially) consults its forwarding table to decide
whether "printer.company.com" on port 380 is an allowed host name
for forwarding, based on the domain name or a domain name pattern.
The domain name pattern table may or may not contain port numbers.
The forwarding table may contain a rewrite rule, e.g., translate
all requests to "printer.company.com" on port 380 to requests to
"printer.outsourceagency.com" on port 3724. Such forwarding and
translation allows services to be redirected without requiring
renaming or reprogramming.
The forwarding or filtering rule for a given host or host pattern
may contain method rules (GET allowed, POST not), which will be
used subsequently in step 4e below.
Step 4d: IP address filtering & forwarding
The proxy looks up the domain name in the HTTP request
"printer.company.com" and gets the IP address for it. The
proxy (potentially) consults its forwarding table for entries
based on IP address, in the same manner as domain names were looked
up in step 4c. As in step 4c, the forwarding or filtering rule
for a given address or address range may contain method rules
which will be used in step 4e.
Step 4e: Method filtering
The proxy (potentially) examines the method against the allowed
methods from the lookup in steps 4c or 4d, and decides whether
the forwarding is allowed.
Note that generally implementations do not do different forwarding
based on method ("if you're POSTing, go to this URL instead"), even
though forwarding based on host or path is common.
Step 4f: forwarding
If filtering in steps 4c-4e have not disallowed the request and
the request is not transformed, a HTTP connection is established to
"printer.company.com" on port 380, using the request URI "/prt32".
Step 5: Origin server
The request arrives at the server either directly from the
client (step 3b-noproxy) or from the proxy (step 4f).
The server sees a request URI of "/prt32" with a HOST header
of "printer.company.com:380".
I could elaborate further any of these steps or any subsequent steps if
it's still not clear how this is supposed to work. However, I sincerely
hope I've made it clear how using an "ipp" scheme can work even when
a client is connecting through a proxy, and that this does not "break all
existing proxies" since in no case does the string "ipp" appear at a
evel that the proxy examines.
Regards,
Larry