Re: 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)

Yep, force of habit -- I'll do a search for the rest (and e.g. as well).

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

Nope -- we can't require a server to understand major versions
greater than their native version.  Ummm, I guess the words around
it could be more explicit in not including <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.

I've only seen asctime() from some PC-based servers -- no browsers.
I don't see any value in dropping it beyond the existing requirement
that it never be generated.

>   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.?

I'd prefer to have such things close to the topic's text, so I guess
that means another note.

> 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?

Yes, I think we got a little overexcited in that section -- it should
not be forbidding anything (except malformed values).

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

okay

> 6.1 Status-line
> 
>   a. [nit] The last sentence ("Although...") should be a note?

Actually, it clarifies an ambiguity in the BNF, so I'd like to leave
it in the body.  I will make it a little less wimpy.

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

That would depend on what was got.  I don't want to forbid something
just because it may not be useful -- if it's not useful, people won't use it.

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

Agreed -- I'll delete evrything after the "--".

> 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?

Er, bad terminology I guess.  That was meant to mean "applies only for
the nearest neighbor in a connection chain" (i.e., the closest server).

> 6.3.2 Retry-After
> 
>   a. [nit] change /an full/a full/

Nix the "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.

Okay.

> 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.)

Okay.

> 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.

That doesn't say much (400 Bad Request can always be returned), but I get
the drift.  It is more appropriate than:

>      [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?

That would have to be approved by a resounding consensus, as it would
remove the possiblity for clients to use packetized encodings to submit
request data of indeterminate size in any of the 1.x protocols.  This
may not be a big deal, but I'm not willing to make that decision.

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

I'd rather not.  In fact, appendix C will probably move to Notes.

> 7.1.9 Last-Modified
> 
>   a. [nit] Spell out 'last-mod'?

Okay.

> 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).

Yes, I've been thinking of that as well.  Location is necessary for
auto-redirects (and can serve as the default URI if URI is not given).
At the same time, URI should be required for URLs subject to content
negotiation variants.

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

No, they serve different needs.  They are quite likely to differ
(e.g., you won't find a URN in a Location header).

 ....Roy T. Fielding  Department of ICS, University of California, Irvine USA
                                       <fielding@ics.uci.edu>
                      <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>

Received on Thursday, 23 March 1995 22:01:27 UTC