They certainly will be literally different if the client is talking dir=
ectly to
the origin server (Request-URI must be an abs_path URI: Relative) and =
IPP
mandates Absolute URIs in application/ipp.
Speculation: they might also be different:
After TLS negotiation?
Where the URIs are semantically the same but syntactically different, e=
.g.:
- Absolute vs. Relative
- host.domain vs dotted-ip
- Default port specified vs. port omitted
- UPPERCASE/lowercase in hostname
- URI translation using equivalent escape codes
After an HTTP redirect handled automatically by an HTTP layer in the cl=
ient
stack that doesn't know about IPP?
Maybe an HTTP proxy server handles a redirect invisibly to the client?
owner-ipp@pwg.org on 05/29/98 04:13:56 PM
Please respond to owner-ipp@pwg.org
To: jkm@underscore.com
cc: ipp@pwg.org
Subject: RE: IPP> New IPP Model Document
Absolutely, I see the advantage of having the IPP information take
precedence, I'm just not sure of the impact of having the two headers
(HTTP and IPP-body) be different, and actually getting this to work in =
a
CGI/NSAPI/ISAPI-based implementation.
The generic web server will dispatch to the HTTP header-specified URI
(I'm assuming, someone correct me if this is not the case). Once this
dispatch occurs, the target in the HTTP header better be able to handle=
whatever is coming in the application/ipp body part. In this scenario,
its too late to apply any precedence.
Has someone identified a case where the two headers have to be
different? (I may have missed some email...)
Randy
-----Original Message-----
From: Jay Martin [SMTP:jkm@underscore.com]
Sent: Friday, May 29, 1998 2:51 PM
To: Turner, Randy
Cc: ipp@pwg.org; Puru Bish
Subject: Re: IPP> New IPP Model Document
Randy,
> This may be a difficult requirement to meet if an IPP
implementation is
> built as an extension to a generic web server (like Apache).
Are you sure about this? I mean, I can see you point to
a certain extent, but wouldn't it be advantageous for an
IPP server implemented as a front-end on a generic platform
to be used as a multiplexor to several Printers and Jobs?
On the other hand, if the HTTP request header takes precedent,
then why are we specifying printer-uri/job-uri at all at the
IPP protocol level? Aren't we asking for trouble when the
HTTP request header and the corresponding IPP attributes don't
match (with regard to interoperability)?
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com
-- -- Underscore, Inc. | Voice: (603) 889-7000-- -- 41C Sagamore Park Road | Fax: (603) 889-2699-- -- Hudson, NH 03051-4915 | Web: http://www.underscore.com ------------------------------------------------------------------------
Turner, Randy wrote: > > This may be a difficult requirement to meet if an IPP implementation is > built as an extension to a generic web server (like Apache). > > Randy > > -----Original Message----- > From: Jay Martin [SMTP:jkm@underscore.com] > Sent: Friday, May 29, 1998 2:34 PM > To: ipp@pwg.org > Cc: Puru Bish > Subject: Re: IPP> New IPP Model Document > > After thinking about this, I tend to agree with Puru's > statement: > > >From "Tom Hastings" > > > > :: In fact, the HTTP request header URI, if persent, takes > precedence" > > (over printer-uri/job-uri operation attributes). > > > > I think it should be the other way around. I feel the > > printer-uri/job-uri, supplied by IPP client, should have > higher > > precedence to an IPP server than the HTTP header URI. > > ...jay > > > ---------------------------------------------------------------------- > -- JK Martin | Email: jkm@underscore.com > -- > -- Underscore, Inc. | Voice: (603) 889-7000 > -- > -- 41C Sagamore Park Road | Fax: (603) 889-2699 > -- > -- Hudson, NH 03051-4915 | Web: > http://www.underscore.com -- > > ----------------------------------------------------------------------
=