W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

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

From: Life is hard... and then you die. <Ronald.Tschalaer@psi.ch>
Date: Wed, 25 Mar 1998 16:59:05 +0200
Message-Id: <98032516590585@psicla.psi.ch>
To: HTTP-WG@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5498

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

    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

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.

    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


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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:22 UTC