Re: NULL-Request (Sect. 4.1)

    I'm somewhat disturbed by calling CRLF a "NULL Request". This seems
    to me to open up a lot of opportunities to fall into holes when
    writing statements like "Every request receives a response code."

    Plus I don't think it quite captures the problem for the server
    writer.  Server writers are going to get extraneous CRLFs appended
    to certain content types and they have to be aware of that.

    I suggest we call it what it is, a KLUGDE (or a hickup). Then we
    are not likely to commit an error later on by inadvertently
    refering to "Requests" and including NULL requests by mistake.

    I think that there should also be a statement to warn server
    writers not to depend on the additional CRLF.
    
I think you are on the right track here.  In RFC791, there is a succinct
description of what has become known as the "robustness principle"

	In general, an implementation must be conservative in its
	sending behavior, and liberal in its receiving behavior.

This was restated in RFC1122, and is generally a good guide for
deciding how to approach this kind of borderline-acceptable behavior.

I suggest that the HTTP spec say something vaguely along these lines:

	(1) Don't send extra CR-LFs in HTTP messages
	(2) The recipient of an HTTP message should ignore CR-LFs
	(and probably other "whitespace") if by ignoring that
	whitespace it can convert a syntactically incorrect message into
	a syntactically correct one without any ambiguity.

In other words,
		you 			all
	c a n
read this 

sentence

even if it looks like e. e. cummings wrote it.

Then we don't need to worry about the complexities of trying to
define a null method, just to avoid honoring the robustness principle.

-Jeff

Received on Wednesday, 24 April 1996 11:11:42 UTC