Thanks for your thorough description of this issue which we discussed
briefly last week during the bake-off. I will bring up your suggestions
in the discussions on the Implementor's Guide on Wednesday.
Carl-Uno
> -----Original Message-----
> From: Carl Kugler [mailto:kugler@us.ibm.com]
> Sent: Monday, September 28, 1998 12:37 PM
> To: cmanro-@cp10.es.xerox.com
> Cc: ipp@pwg.org
> Subject: IPP> PRO> Requirements on use of HTTP/1.1 in IPP
>
>
> Carl-Uno-
>
> 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-existing HTTP
> frameworks, software development kits, or protocol stacks.
> These are provided
> 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 variety of
> HTTP applications.
>
> Philosophically, I believe that the IPP spec should be as
> unambiguous and
> rigorously defined as possible. This improves
> interoperability. However, 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 areas 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 the
> 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 absolute
> requirement of the IPP specification. We should make our
> recommendations, 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 HTTP stacks
> that work fine for other applications will be likely to work
> fine for IPP,
> too.
>
> I presume that IPP tries to subset HTTP/1.1 for the benefit
> of implementors
> building their own HTTP layers. But I think the practical
> reality is that some
> variations of HTTP/1.1 will have to be accommodated for in
> any implementation
> that wants to interoperate widely with others. Also, the
> amount of HTTP
> functionality needed for an IPP implementation is pretty
> lightweight, even
> 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 transport
> 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 layer is
> defined by draft-ietf-http-v11-spec-rev-05 (or whatever),
> with all of it's
> vagueness, leniency, and backward compatibility, not as
> saying that a message
> 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 context of CGI
> scripts, the HTTP layer removes any chunking information in
> the received
> data."
> This statement is irrelevant and confusing. Any HTTP/1.1 application
> (including an IPP implementation) must be able to receive and
> decode the
> chunked encoding. That's what the ietf-http-v11-spec says,
> and we should leave
> it at that.
> PRO> "A client MUST NOT expect a response from an IPP server
> until after the
> client has sent the entire response. But a client MAY listen
> for an error
> 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 chunk 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 this
> intention with the "Expect: 100-Continue" HTTP header. "The
> purpose of the
> 100 (Continue) status (see section 10.1.1) is to allow an
> end-client that is
> sending a request message with a request body to determine if
> the origin 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
> inappropriate or
> highly inefficient for the client to send the body if the
> server will reject
> the message without looking at the body." I don't see why
> IPP should prohibit
> this.
> PRO> (in table): "General-Header: Connection: "close"
> only. Both client
> 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 header when
> this condition is met."
> This is connection management. This use of persistent
> connections should be a
> recommendation for performance enhancement, not an absolute
> requirement of the
> IPP spec. Also, why say "'close' only" and effectively
> prohibit the use of
> "Connection: Keep-Alive", which is commonly used by HTTP
> implementations
> 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 server
> always determine whether or not the current operation is the
> last operation in
> a sequence of operations?
> Finally, the requirement to send Cache-Control headers is
> redundant since the
> HTTP spec prohibits caching for POST requests anyway.
> -Carl
>