As you requested at the bake-off, I am putting down some of my thoughts=
about
IPP's restricted use of HTTP/1.1.
It was clear at the bake-off that many implementors are using pre-exist=
ing HTTP
frameworks, software development kits, or protocol stacks. These are p=
rovided
by operating systems, development frameworks, web servers, etc. I have=
yet to
see an off-the-shelf HTTP implementation that is not somehow broken in =
its
support for HTTP/1.1. Yet many of these implementations somehow manage=
to get
the job done for millions of users, daily, around the globe, in a varie=
ty of
HTTP applications.
Philosophically, I believe that the IPP spec should be as unambiguous a=
nd
rigorously defined as possible. This improves interoperability. Howev=
er, it
does not improve interoperability when IPP tries to remove some of the
ambiguity in the HTTP/1.1 spec. Http-wg members admit that the HTTP/1.=
1 spec
is intentionally vague in some areas, because it is felt that those are=
as are
not understood well enough to be fully nailed down, and only experience=
with
what works in practice will provide the understanding. A good example =
of this
is connection management. The HTTP/1.1 spec is silent about who closes=
connections and when and why. Also, the HTTP/1.1 spec itself provides =
for a
lot of leniency and backward compatibility with HTTP/1.0.
Therefore, I think the IPP specs should avoid putting restrictions on t=
he
HTTP/1.1 transport layer. It would be a good idea to recommend use of =
HTTP/1.1
features like persistent connections, but this should not be an absolut=
e
requirement of the IPP specification. We should make our recommendatio=
ns, but
defer to the HTTP/1.1 spec when it comes to MUSTs and SHOULDs about the=
transport layer. If HTTP/1.1 allows for some vestiges of HTTP/1.0 for
compatibility's sake, we should too. That way, generally available HTT=
P stacks
that work fine for other applications will be likely to work fine for I=
PP,
too.
I presume that IPP tries to subset HTTP/1.1 for the benefit of implemen=
tors
building their own HTTP layers. But I think the practical reality is t=
hat some
variations of HTTP/1.1 will have to be accommodated for in any implemen=
tation
that wants to interoperate widely with others. Also, the amount of HTT=
P
functionality needed for an IPP implementation is pretty lightweight, e=
ven
allowing for backward compatibility. The real weight is in areas like =
the
encryption layer.
Specifics
-------------
Below are some specific areas where IPP puts restrictions on the HTTP t=
ransport
layer that go beyond what's in the HTTP/1.1 spec.
PRO> "HTTP/1.1 is the transport layer for this protocol. "
We should allow that to be interpreted as saying that the transport lay=
er is
defined by draft-ietf-http-v11-spec-rev-05 (or whatever), with all of i=
t's
vagueness, leniency, and backward compatibility, not as saying that a m=
essage
must be rejected if says HTTP/1.0 in the message header.
PRO> "The IPP layer doesn't have to deal with chunking. In the contex=
t of CGI
scripts, the HTTP layer removes any chunking information in the receive=
d
data."
This statement is irrelevant and confusing. Any HTTP/1.1 application
(including an IPP implementation) must be able to receive and decode th=
e
chunked encoding. That's what the ietf-http-v11-spec says, and we shou=
ld leave
it at that.
PRO> "A client MUST NOT expect a response from an IPP server until aft=
er the
client has sent the entire response. But a client MAY listen for an er=
ror
response that an IPP server MAY send before it receives all the data. =
In this
case a client, if chunking the data, can send a premature zero-length c=
hunk to
end the request before sending all the data. If the request is blocked =
for some
reason, a client MAY determine the reason by opening another connection=
to
query the server."
The ietf-http-v11-spec says that the client MAY expect a response from =
an HTTP
server before the client has sent the entire request, IF it announces t=
his
intention with the "Expect: 100-Continue" HTTP header. "The purpose o=
f the
100 (Continue) status (see section 10.1.1) is to allow an end-client th=
at is
sending a request message with a request body to determine if the origi=
n server
is willing to accept the request (based on the request headers) before =
the clien
t sends the request body. In some cases, it might either be inappropria=
te or
highly inefficient for the client to send the body if the server will r=
eject
the message without looking at the body." I don't see why IPP should p=
rohibit
this.
PRO> (in table): "General-Header: Connection: "close" only. Both cli=
ent
and server SHOULD keep a connection for the duration of a sequence of
operations. The client and server MUST include this header for the last=
operation in such a sequence. The client or server MUST send the heade=
r when
this condition is met."
This is connection management. This use of persistent connections shou=
ld be a
recommendation for performance enhancement, not an absolute requirement=
of the
IPP spec. Also, why say "'close' only" and effectively prohibit the us=
e of
"Connection: Keep-Alive", which is commonly used by HTTP implementation=
s
because it was an extension to HTTP/1.0 to allow persistent connections=
before
HTTP/1.1 made persistent connections the default? Can the client or se=
rver
always determine whether or not the current operation is the last opera=
tion in
a sequence of operations?
Finally, the requirement to send Cache-Control headers is redundant sin=
ce the
HTTP spec prohibits caching for POST requests anyway.
-Carl
=