IPP Mail Archive: IPP> IIG> Tables of HTTP header fields

IPP Mail Archive: IPP> IIG> Tables of HTTP header fields

IPP> IIG> Tables of HTTP header fields

From: Dennis Carney (dcarney@us.ibm.com)
Date: Wed Aug 15 2001 - 19:52:51 EDT

  • Next message: Bob Long: "IPP> Need a Home Loan? We Can Help!!"

    I have some questions on some entries in the tables in section "7 Encoding
    and Transport" of the IPP/1.1 Implementer's Guide, dated 7/17/2001. I hear
    that the IIG is in the middle of a revision, so I think this is a good time
    for my issues. Please forgive me if I am getting too picky here--just let
    me know and I'll shut up!

    Specifically:
    - "Connection" header field. Both the Request/Server and Response/Client
    entries are "must". However, for clients that do not wish to have a
    persistent connection (that is, that included "Connection: close" on the
    request), or for servers that do not support persistent connections (that
    is, that include "Connection: close" on every response), there is no need
    to parse the incoming Connection field. Should these entries be "must-if",
    with a description that the client or server must support this header field
    only if they are expecting a persistent connection?
    - "Content-Encoding" header field. The Response/Server entry is "must",
    indicating that the server must include the Content-Encoding header field.
    However, RFC 2616 says that a Content-Encoding header field should only be
    used when the encoding is not "identity". Should this entry be a
    "must-if", saying that Content-Encoding must be included if the encoding is
    not "identity"?
    - "Content-Encoding" header field. The Response/Client entry is "must".
    But if a client sends the "Accept-Encoding" header such that only one
    encoding is acceptable (e.g. "Accept-Encoding: identity"), there does not
    seem to be a great need to look at the "Content-Encoding" returned in the
    response. A correctly-written server will either give the client the
    encoding it wants, or fail the request with 406 "Not acceptable". A
    less-than-correctly-written server might give the client an encoding it
    doesn't understand, but spending time to check the Content-Encoding header
    or simply trying to parse the IPP and failing will both pretty much end up
    with the client putting up some sort of "Unreadable response" error.
    Should this entry be a "must-if", saying that Content-Encoding is optional
    for clients that have used the "Accept-Encoding" header to indicate support
    for only one encoding, and mandatory otherwise?
    - "Content-Type" header field. The Response/Client entry is "must". But
    it seems as if any response with HTTP 200 OK will always have
    "Content-Type: application/ipp" (since the Response/Server entry is a
    "must"), and all other HTTP responses won't. So does the client really
    need to check this? For example, if a client sent an IPP request, got back
    an HTTP 200 OK, but there was no Content-Type field (or a Content-Type
    other than application/ipp), should we really force the client to consider
    this as a bad response, or should we give the client the option to go ahead
    and try to parse the response as IPP anyway? Should this entry be a "may"?
    - "Accept" header field. The Server entry is "must". By the same
    argument, should this be "may"? (That is, do we want to *force* servers to
    reject requests that come in on port 631 but that have an Accept value
    other than application/ipp?)

    It is possible that some of my issues have to do with what exactly the
    document means when it says a client/server must "support" a header. If
    the header can have only one value, does "supporting" it mean that the
    recipient must verify that it is there with the right value? Or does it
    only mean the recipient must tolerate the existence of the header?

    Comments?

    Dennis Carney
    IBM Printing Systems (303)924-0565



    This archive was generated by hypermail 2b29 : Wed Aug 15 2001 - 19:53:40 EDT