Comments on HTTP draft [of 23 Nov 1994]

I was very pleased to see the new HTTP draft; it's a major improvement
on previous versions!  Here are some comments on the new draft which I
hope will be useful.

I am writing these from the perspective of an implementer of software
for a reasonably general-purpose HTTP server, so I am especially looking
for a definition of the HTTP which

 a) allows a server to be implemented using the definition (and
    referenced documents) and specifically without reference to specific
    clients or other implementations

 b) makes it absolutely clear what is required for a server to be stated
    as conforming to the definition.

Most of these comments therefore seek clarification in these two areas.

I'm sorry I won't be able to attend the IETF meeting next week--a
long-standing commitment has me on the wrong coast of the USA.

Mike Cowlishaw
IBM Fellow, IBM UK Laboratories, Winchester, UK

- - - - - - - - -

2.1 The '#' rule implies that no whitespace is allowed after (or before)
    the commas in a list.  Is this correct?  For example, in the example
    in 7.1 there is a space after each comma (which certainly aids

2.2 linear-white-space rule: I didn't understand the comment "CRLF =>
    Folding".  I think this rule allows whitespace (but non-null) lines
    in headers etc.?

3.1 Header fields:

    (a) "However ... use of comments is discouraged".  This seems rather
    outside the scope of a definition such as this; at most it should be
    a informational note, and explain why the note is there (historical
    or client incompatibility, performance, reduced net traffic?).

    (b) [nit] the second open quote in the comment rule should be a
    close quote.

    (c) The ctext rule seems to be missing some characters (there's an
    open quote, followed by an open single quote, but neither is
    closed).  Also, shouldn't LF be excluded too?

3.2 Object body:

    (a) This is my 'biggest' question -- I don't understand from the
    second paragraph how to determine when to stop reading the data on a
    request.  If the headers are only 'similar' to those defined by
    MIME, then the MIME definition may or may not be relevant.
    Moreover, a "heuristic function of the Content-Type and
    Content-Encoding" would appear to be unimplementable, as new Types
    (especially application/xxx) seem to spring up daily.

    It would seem to be appropriate that the HTTP protocol specify that
    Content-Length, in bytes, be Required--at least for Requests.

    (b) Does the server have to read the headers (and data, if any) on a
    request?  For example, if the customizing filter/script doesn't need
    the information in order to determine the response, is the server
    permitted to leave the data unread, or could this embarrass some
    client(s) or TCP/IP stack(s)?

4.1 Date/Time stamps:

    (a) I'm a little disturbed that time is only permitted to be
    specified to the second, given that most server hardware will be
    able to handle many more than one request per second, and network
    transit time is often sub-second.  If this is a limitation of RFC
    1123, perhaps an additional HTTP header for sub-second time
    information should be specified.

    (b) Since this is a new standard/document, surely it should specify
    a single Date/Time format, and only mention the others for
    compatibility/historical information?

    (c) [aside] I wish, oh wish, that Longitude/Latitude information
    were a recommended header.

4.2 Multipart types: From the text, I infer that a server/script is
    not Required to respond with a multipart type when a client has
    indicated that it can accept them.  It might be worth an explicit
    statement to that effect.

4.3.1 Date Header Field:

    (a) [nit] should refer to RFC 1123 rather than 822, or both?

    (b) It's not clear what time the header should refer to.  For a
    response, is it the time when the request was accepted, or when the
    response line was generated, or when the first line of the header
    was transmitted, or when the 'Date:' header line was generated?

    (c) [nit] 'of' is missing between 'creation date' and 'the

4.3.3 Message-ID: [suggestion] Although the example shows a unique ID,
    it might be nice to encourage via the example a form of ID that
    includes the port number (if not 80), and even follows URL format.

      Message-ID: <>

4.3.4 MIME version: It is not at all clear why this is useful and
    strongly recommended if it is not an indication of full compliance
    with MIME.  One might argue that it should *not* be included unless
    MIME-compliance of the remainder of the header and data is

5.  Request: The 0.9 requirement here (Simple Request must have Simple
    Response) is somewhat onerous on a server.  Is it possible to relax
    or remove this requirement yet, or are there still 0.9-only clients
    in use?  I've noticed that at least some Simple Responses will not
    go through some proxies transparently.

5.2 Method and 5.2.2 Head: I'm surprised that the HEAD method *must* be
    supported, as it is ill-defined.  5.2.2 simply says that there must
    be no Object-Body; it seems that the header may or may not be
    related to the header that would be sent if the method were GET, and
    in particular, HEAD may as well just return an empty (null) header.

    Further, in many cases the cost of determining, building and sending
    the header is going to be the major part of many transactions, so
    should clients or proxies be encouraged to use this Method?

5.2.1 Get: [nit] The first paragraph should have the suffix: "(unless
    that is the produced data)."

5.2.3 Post:

    (a) Some clarification seems to be needed here; there's an
    assumption that Form data is used by some gateway program rather
    than the server/script directly, but in the latter case the
    specification (the paragraph starting "If the URI does not refer to
    a gateway...") implies that the Form data must be retrievable at
    some later date.

    (b) Can the URI returned via a URI-header be a partial URI as
    described in 5.4?  Or does it have to be a full URI?  [I infer the
    latter.] [nit] Change 'references' to 'refers to'?

5.3 HTTP Version: Given that this definition is more rigorous than
    earlier documents, and hence must be more constraining, it would
    seem to be necessary to change the version number (perhaps to 1.1)
    to reflect the stricter conditions for compliance.  If the version
    number is not changed, then the date of the relevant HTTP 1.0
    document would have to be specified at every reference.

5.4 URI Note 1: What's 'default escaping'?  What characters may be
    'considered unsafe'?  The "should" (probably meant to be "shall"?)
    implies that a server must comply with these conditions, but they do
    not seem to be well defined.

5.5.2 If-Modified-Since: This section implies that servers *must*
    implement this feature.  However, the last-modified-date might be
    unavailable, unreliable, or not applicable for some URIs.  In these
    cases (or indeed in any case), is the server permitted to return the
    object, despite the presence of the I-M-S header?

5.5.4 Authorization: UU-encoding: if defined by RFC 1421, then this
    should appear in Section 13 (References), and Appendix 15 should go
    away (as it does not appear to apply, in any case)?

6.3 Status Codes and Reason Phrases: The rule for Reason-Phrase does not
    allow spaces, but several of the phrases specified later do include
    a space.

6.3.1 201 Created: Also possible following PUT, presumably.

6.3.1 202 Accepted: "delay header line" is what?

6.3.1 204 No Response: Allowed for POST, too?  (For a Form.)

6.3.2 301 & 302 Moved: Allowed for POST, and others, too?

6.3.3 401 Unauthorized: [nit] change first 'a' to 'an'.

6.3.3 404 Method Not Allowed: is this only for the defined methods, or
    should this also be used for a misspelled or unrecognized method

6.3.4 500 Server Error: 502 (twice) and 504 call this "500 Internal
    Error".  All should say "Server Error"?

6.3.4 503 Service Unavailable: Does this imply that a server is not
    permitted to refuse to accept a connection?  [Presumably not, though
    it could be read that way.]

6.4 paragraph 1: [nit] change 'a Object-Body' to 'an ...'

6.4.2 Version: since this refers to an object and not the server,
    shouldn't it be in section 7?

7.2 Content-Length Note 2: [nit] 'wherever' has only three 'e's.

7.4 Content Encoding:

    (a) [nit] this heading (and 7.5 too) needs a hyphen.

    (b) [nit] change 'method' to 'mechanism' in the first paragraph to
    avoid confusion with use of the term elsewhere?

7.5 C-T-E: The rule omits the token and colon before the type.

7.7 Expires: Are there any constraints on the Date and Time specified?
    Specifically, may they refer to a time earlier than or the same as
    that in the Date: header?

7.9 URI First example: [nit] Change close quote to open quote.

7.9 URI Second example: [nit] Semicolon missing.

7.12 Title: "isomorphic" here implies that the Title follows SGML
    syntax, and hence depends on the HTML DTD (including the
    Declaration), and is allowed any valid entities and shortrefs
    within, etc.  This probably isn't intended (I hope!).

7.13 Link: [nit] both examples have unmatched quotes.  '//' missing
    after 'mailto:'?

8 Neg. algorithm para 4: [nit] change 'between 0 and 1' to 'in the range
    0 through 1'?  (0 and 1 are allowed values.)

8 Neg. algorithm 'bs' definition: [nit] change 'send' to 'sent'

9 Authentication, paragraph 1: Here is perhaps the strongest statement
    in the document about conformance.  Yet, surely, if the server would
    never return "401 Unauthorized" (because all its data are public)
    there is no need for it to implement the Basic Access Authentication

9 Authentication, fourth bullet: [nit] change second 'a' to 'an'.

11.3 Abuse, para 1: While I strongly support the intent behind the last
    sentence here, this document is a definition of the HTTP protocol,
    not people using it.  It cannot impose requirements on, or define,
    people.  (Does my server become non-conforming because someone using
    my server abused his or her collected data?)  Also, am I (as the
    writer, and hence provider, of a server) responsible for the actions
    of other people *using* my server to provide data?  Thin ice...

    Perhaps it should read something like: "People using the HTTP
    protocol to provide data are responsible for...".

11.3 Abuse, final para: This reads as though the user must be prompted
    with the From field to be sent before sending every request.
    Probably not the intent.

16  Server Tolerance, para 2: Time to make this a Requirement?

17  Bad servers: The first paragraph here sounds like a Compliance
    statement.  As such, it should be in the body of the document, not an
    appendix?   The document certainly needs a Compliance section.

17.1 Back compatibility, para 2: This doesn't seem to reflect current
    practice (inline <img href="xxx"> requests for .GIF files do seem to
    appear as images, not as HTML documents).

mfc/29 Nov 1994

Received on Tuesday, 29 November 1994 08:16:57 UTC