Re: Submitting errata

Larry Masinter wrote:
> I think the errata in question is hinted at in
> 
> 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

Received on Sunday, 18 April 2004 21:34:56 UTC