Subject: Re: Submitting errata

From: Larry Masinter <[email-masked]>
Date: Sun, 18 Apr 2004 16:55:44 -0700

I think the errata in question is hinted at in

http://lists.w3.org/Archives/Public/ietf-http-wg/2004JanMar/0060.html

but it would be nice to write up a summary of how
the spec should actually change, so that we can judge
'consensus' on the proposed text.
 
Note that Scott Lawrence maintains a HTTP errata page

at    http://purl.org/NET/http-errata

> AFAIK, IETF does not have a formal mechanism for submitting errata.

http://www.rfc-editor.org/errata.html says

   To report suspected errors that are more technical
   in nature, please verify the errors with the authors
   and/or appropriate area directors of the IESG before 
   sending them to the RFC Editor for posting. 

In this case, though, we got the RFC editor to point to
Scott's page.

Jim Gettys claims that
  draft-gettys-http-v11-spec-rev-00.txt

already includes all of the existing errata, so, once
there is clear agreement, the change could also be
incorporated.

Larry
-- 
http://larry.masinter.net

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 19 Apr 2004 02:33:42 +0100

> http://lists.w3.org/Archives/Public/ietf-http-wg/2004JanMar/0060.html

That's one of them.  (Despite the subject of that message, that
specific message is about 100 Continue and when to send it).

The others are:

   2. Clarification of whether LWS is permitted before the colon in
      headers.  Various people understand the RFC differently, as can
      be seen in their implementations.

   3. Require agents to reject messages with malformed field names,
      and perhaps field names which have LWS before the colon,
      because not doing so leaves open certain security holes due to
      proxies and other intermediate agents not recognising or filtering
      headers that are interpreted by another agent.

      Notably, headers with LWS _before_ the field name should be
      rejected.  (Yes, certain widely used software treats it as part
      of the name when it's the first header line, instead of as a
      continuation line, and other widely used software skips the LWS
      there).

      If LWS is not permitted before the colon, messages with that
      should be reject as well.  (Even if it's decided that RFC2616
      permits LWS there, in my opinion it makes sense to decide that
      LWS should not be permitted there, and require implementations
      to reject any message which has it.  Nobody sends messages with
      LWS there (because most agents don't accept it), and rejecting
      it closes a potential security hole.  Note that rejecting it is
      different from Apache's old behavior, which was to accept LWS
      there and treat it as part of the field name, thus passing along
      a dangerous name through it's proxy).

   4. Suggest agents reject messages with CR in any part of the header,
      except as part of the CR NL sequence.  Again potential security
      holes: some proxies split lines on any of CR, NL or CR NL.
      Working around deployed bugs yes, but the implementation
      suggestions may as well recommend this.

      Practical implementation issue: NL CR CR NL is known to end the
      headers from some very old servers, so robust clients accept it
      and this is documented in a few places.  Not sure if CR CR NL
      has been used to end non-empty header lines, but it's easy to
      see how this could arise, from quirky CGI implementations.

   5. Clarification as to whether it's ok to send any part of a response
      before reading all of the request body and whether a client should
      accept that.  The RFC text _seems_ to indicate that this should work,
      for non-"error status" responses only, with complient agents.

      But I may have misunderstood it, and there's no doubt that some
      implementors have misunderstood or ignored section 8.2.2.

      This is potentially useful for a server which does on-the-fly
      translation of a submitted request: the streamed request could
      be translated on-the-fly to a streamed response.  This is
      potentially useful even for web browsers, hence the reason for
      testing against those.

      This also has other streaming uses: using an HTTP
      request-response pair as a substrate for another bidirectional
      protocol, temporarily.

      Tests with many clients indicate that its ok with most of them,
      and some clients accept the response while continuing to stream
      the request, while others stream the whole request before
      accepting the response, so servers must be prepared to keep
      reading the request even when response writing blocks (to
      prevent deadlock).  If the server does that, for all of these
      clients this method can be used.

      However, I saw failure with Mozilla 1.2, which seems to abort
      the request on seeing part of the response even if it's 200 OK,
      but I did not have enough time to investigate properly.  Didn't
      try any version of MSIE.

      It would be good to know whether this is ok (a) in theory
      according to the standard; (b) in practice.  The RFC errata
      should at least clarify (a).

   6. What is the definiton of "error response" as used in section
      8.2.2.  It may be that the words "error response" will be
      deleted in order to clarify point 5 above, which would make
      point 6 moot.

-- Jamie

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 19 Apr 2004 10:31:34 -0600 (MDT)

Jamie,

	As suggested by Larry and myself, it is probably time for you
to post specific, concise changes to RFC 2616. After a discussion,
some or all of those changes can be incorporated into RFC errata.

	We have discussed these issues. Some of them seem pretty
straightforward specification bugs, some may be less appropriate for
an errata. Hopefully, this semi-idle group would be able to come to
rough consensus once you post specific changes. If not, you can always
try to contact IETF IESG directly, but, again, you will need specific
changes written up and discussed here first.

	Please post specific errata, how you want it to appear on the
official errata page. Dedicating a single e-mail subject/thread to
each change you post may be a good idea.

Thank you,

Alex.