Re: NULL-Request (Sect. 4.1)

>
>Date:  Wed, 24 Apr 96 09:59:07 EDT
>From:  dmk@allegra.att.com (Dave Kristol)
>To:  fielding@avron.ics.uci.edu
>Subject:  Re: NULL-Request (Sect. 4.1)
>Cc:  http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>
>
>"Roy T. Fielding" <fielding@avron.ICS.UCI.EDU> wrote:
>  > > [DMK]
>  > > I believe NULL-Request was added to handle the lingering CRLF following
>  > > a POSTed entity body.  It may have an unexpected and unintended
>  > > interaction with persistent connections:  because the NULL-Request has
>  > > no HTTP-Version and no Connection header, the server is obliged to
>  > > close the connection after servicing the NULL-Request.
>  > 
>  > Well, Dave, I must say that you have a perverse way of reading specs
>  > that discovers problems I would never even dream of.  ;-)
>
>Um, thanks, I guess.  It comes from intense language lawyering for the
>ANSI C spec.

I applaud such perverted minds; I disagree with some of the conclusions
below, however.

>
>  > I've noticed that some implementers manage to derive similar
>  > interpretations, so I'm glad you find them first.
>
>Well, I found it because indeed I was trying to figure out exactly how
>to implement null requests and noticed the presumed unintended
>side-effect.
>  > 
>  > Any thoughts as to what/where words need to be added to prevent this
>  > unfortunate event?
>
>Not really.  The NULL-Request idea seems attractive at first glance,
>but it makes me nervous that a server should silently eat and discard
>an arbitrary number of blank lines (assuming the persistent connection
>issue gets side-stepped).  That opens the gate for a malicious client
>to mount a denial of service attack by pumping a stream of CRLF's at a
>server.  I'm more inclined to deal with it as a special-case hack:
>
This is a red herring.  There are N denial of service attacks possible
on an HTTP server where N is probably measured in thousands.  This one
is no more serious than any of the others.  A common response will be
for servers to close connections if they have served many requests
on the same connection.

More realistically, a single server is likely to round robin between
connections; the NULL-request will just be the request from that
client (and be particularly fast to determine there is no work to do
(if I were doing a deliberate attack, I'd pick requests that take
alot of work by the server to do, not a no-op that would immediately
get me back to a schedular of some sort.)
  
>- if there is a POST, and
>- if the connection is held open,
>- (and if the request is HTTP/1.0?),
>the server should look for, and silently discard, a CRLF that follows
>the entity body.
>Dave
>

Protocols can only stand so many special purpose hacks.  If you
continue to add things like this that are special case everwhere
on a per method basis, there lies long term madness.  No one will get
implementations right, and interoperability suffers (not to mention
spagetti code everywhere).

It seemed to use like a less obtrusive solution to the problem of
existing broken post scripts was to add a general no-op (also somewhat
useful for performance measurements) rather than bandaid the post
method.  I believe you need to look at this solution in that light.
And I'm glad you're mind is so strange as to find the problems in
it as first written.
				- Jim

Received on Wednesday, 24 April 1996 10:01:56 UTC