- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Fri, 19 Jan 2007 12:34:51 -0800
- To: <LMM@acm.org>
- Cc: <ietf-http-wg@w3.org>
On Jan 19, 2007, at 11:05 AM, Larry Masinter wrote: > In my opinion: > > * The current spec is ambiguous, and needs clarification The current spec needs a complete rewrite. Besides that, the entire ABNF has to be rewritten in order for it to meet current IETF reqs. I suspect that will cause a lot of implied LWS to disappear. > * Although, in general, it is not appropriate to 'tighten' > a specs requirements, in some cases (and in this case) > it is the right choice: > > There are few clients that send LWS between header > name and :. > > There are already many servers that reject such > requests. I think the spec should reflect the standard, not be artificially restricted by adherence to past revisions of itself. By standard, I mean the measure expected by all of the implementations that are exchanging legitimate communication via HTTP. AFAIK, there are no servers or clients that send legitimate messages with anything other than Field-name: field-value so it is time for the spec to reflect that fact. My only caveat is that there should be an exception for the message/http media type, such that messages received via SMTP shall allow line folding. > So, in my opinion, we should change the spec that > clients MUST NOT send LWS in headers before the :, > and that servers MUST reject any such message as > malformed. > > This may make a few servers that were previously > compliant non-compliant, but in general it will > improve interoperability and security. No, I will not accept that. MUST NOT send such LWS is fine, including when a message is forwarded, but forbidding a server from processing such a message is not going to happen because it would make all implementations non-compliant. Servers should be configurable in regards to robust or restricted parsing behavior, and nothing we say can improve the "security" of broken software that was deployed years ago. Software that correctly parses according to the RFC is not subject to those perceived security issues. ....Roy
Received on Friday, 19 January 2007 20:34:58 UTC