Comments on HTTP/1.0 draft [March 8, 1995]

Herewith comments on the latest draft, as requested.  Nothing too
serious!

3.1 HTTP Version, para starting "HTTP servers are.."

  a. [nit] "i.e." needs a following comma (possibly elsewhere also)

  b. <major> should be <major+1> ?

3.3.1 Full date

  a. I haven't ever seen the asctime() format arrive at any of my
     servers -- can this be dropped as a requirement?  RFC 850 does
     still seem to be around, however.

  b. "recipients of date values should be robust in accepting..."
     -- this is really too vague to be implementable.  Make it a
     non-normative note or (better) move to Appendix C.?

4.3.3 Message-ID

  a. I implemented this as per the previous draft and found it useful
     for testing, but I agree that it should not normally be generated.
     I now generate it only in a 'Test mode'.  However, the new text
     forbids this.  Add this case as a possibility?

5.2.3 POST

  a. [nit] change "usually a form" to "such as the result of submitting
     a form" (or something like that)?

5.4.1 Accept

  a. [aside] I applaud the change of emphasis here.

6.1 Status-line

  a. [nit] The last sentence ("Although...") should be a note?

6.2.1 202 Accepted

  a. "Any method" seems a bit strong .. doesn't seem very useful for GET
     or HEAD.

6.2.3 407 PAR

  a. [nit] "will be available in future versions" puts a constraint on
     the future (and future standards processes). Weaken?

6.3.1 Public

  a. Don't understand the "applies only to the current connection".
     Since the request has already been received, and the response
     connection is about to be closed, this implies that the information
     must immediately be discarded, and is hence useless?

6.3.2 Retry-After

  a. [nit] change /an full/a full/

7.1 Entity Header Fields, Note

  a. "It has been proposed.." probably should be moved to HTTP/1.1?  In
     particular, duplication of keywords in two separate address spaces
     between two different layers of protocols (HTTP and HTML) is bound
     to lead to problems in the future (standards will have to be
     tightly bound and coordinated).

  b. "Base will be used..." same comment as 6.2.3 above.

7.1.1 Allow

  a. [nit] A cross-reference back to Public (6.3.1) similar to the Allow
     reference there, would be helpful.  (Or drop the earlier
     cross-reference.)

7.1.4 Content-Length

  a. Add sentence to the effect that if Content-Length is not specified
     on a request, and the server does not recognize or cannot calculate
     the length from other fields, then 400 Bad Request may be returned.

     [aside] I still would prefer that Content-Length be required on
     requests with entity data, as it allows a too-large request to be
     rejected before reading an excess of data first.  Perhaps for 1.1?

7.1.8 Expires

  a. [nit] The note could be moved to Appendix C.

7.1.9 Last-Modified

  a. [nit] Spell out 'last-mod'?

7.1.11 Location

  a. This ("considered obsolete") is inconsistent with 7.1.13 URI, which
     encourages both.  It would perhaps be better to formalize Location
     as a useful special-case of URI (especially as it is very much
     common current practice).  Otherwise, servers must wastefully
     generate both indefinitely (and clients have no incentive to
     implement URI, perhaps).

  b. What happens if both Location and URI are specified, but differ?
     It would be better if one or other (only) were permitted?

Mike Cowlishaw
IBM UK Labs.

Received on Tuesday, 21 March 1995 06:21:09 UTC