Re: NULL-Request (Sect. 4.1)

I think we are in danger of getting into a rat hole here. Or maybee we are 
alrteady in it and are setting about widening it :-)


The problem I see with NULL-Request is that certain IESG entities have a "wart 
alarm" that goes off when an ugly kluge makes its way into a spec. There is a 
tension here between the "keep it clean" brigade and the "make it work" brigade. 
As a longstanding member of the "keep it clean" brigade and a somewhat extreeme 
one I think that in this case we need to be carefull.

Given that we are talking about HTTP/1.1 is there any reason why we cannot 
change the statement "clients SHOULD NOT send a NULL-Request" to "clients MUST 
NOT generate a NULL-Request". Here I would differentiate send from generate in 
that a client generates a message and a proxy recieves input and passes it on. 
In this case it might just possibly be permissable for a stupid proxy such as a 
tunnel to send across spurious CRLFs.


As for Roberts "attach them to the next message" hack. It doesn't work since a 
problem is caused by TCP/IP stacks which send out ABORT if a connection is 
closed with unread data in the input buffer. This has been a reason for many 
Windows HTTP servers loosing. 

I think that what we need is some "speed bump" warning notice somewhere. There 
is a tension here between the traditional IETF approach of "describe the spec, 
the whole spec and nothing but the spec" and the "implementation guide" 
approach. I think that a large part of the reason for the thickness of the spec 
is not the complexity of HTTP itself but the complexity of the implementation 
space. The implementation guide approach is the best way to get people to write 
to the spec IMHO. We might have a problem with getting the merits of this case 
over with the IESG.


I defend the 123 pages of HTTP as being approximately $10million of IPO market
capitalization per page making each page worth approximately as much as an
original copy of Magna Carta.

	Phill

Received on Wednesday, 24 April 1996 17:41:14 UTC