Re: Submitting errata

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.


On Mon, 19 Apr 2004, Jamie Lokier wrote:

>
> 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 Monday, 19 April 2004 12:31:39 UTC