Issues with draft-ietf-http-v11-spec-rev-03.txt

A few issues with draft-ietf-http-v11-spec-rev-03.txt.

1)
    3.7.2: Mutipart Types

    ...
    CRLF to represent line breaks between body-parts. Unlike in RFC 2046,
    the epilogue of any multipart message MUST be empty; HTTP applications
    MUST NOT transmit the epilogue (even if the original multipart contains
    an epilogue). These restrictions exist in order to preserve the self-
    delimiting nature of a multipart message-body, wherein the "end" of the
    message-body is indicated by the ending multipart boundary.

This seems to indicate that all multipart message-bodies are self
delimiting. However, section 4.4 allows only the multipart/byteranges to
be self-delimiting (i.e. all others must be delimited by one of the other
methods).

This is probably too late in the game, but given the above quote why does
Section 4.4 only use multipart/byteranges, and not allow all multiparts
to be self delimiting? Alternatively, if section 4.4 is left as it is,
the above quoted paragraph should be restricted to multipart/byteranges.


2)
    5.1.2. Request-URI

    ...
    In requests that they forward, transparent proxies MUST NOT rewrite the
    "abs_path" part of a Request-URI in any way except as noted above to
    replace a null abs_path with "*", no matter what the proxy does in its
    internal implementation.

Two things:
- "... as noted above ..." - this seems to be left over from earlier
  drafts, as this isn't noted anywhere anymore.

- I've become somewhat confused: when a client is sending an "OPTIONS *"
  (or a "TRACE *") request via a proxy, should it use
  "OPTIONS http://www.some.server HTTP/1.1" or "OPTIONS * HTTP/1.1"?
  The above quote (and the text further up) indicates the former
  (rfc-2068 behaviour), but then why was the example removed from this
  section? I went back and looked at draft-ietf-http-options-02.txt for
  enlightenment, but it didn't help.
    
  So, while I found rfc-2068 nice and clear I can't say the same about
  the current draft.


3) minor typo:

Section 14.11, line 6020:

  If the content-coding of an entity is not "identity", then the response
  MUST including a Content-Encoding entity-header (section 14.11) that
             ^^^

    should be

  If the content-coding of an entity is not "identity", then the response
  MUST include a Content-Encoding entity-header (section 14.11) that



  Cheers,

  Ronald

Received on Wednesday, 25 March 1998 08:05:41 UTC