Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Sat, 7 Aug 2004 19:51:29 -0400
From: Glenn Strauss <gs-apache-dev@gluelogic.com>
To: dev@httpd.apache.org
Subject: Re: POST without Content-Length
Message-ID: <20040807235129.GA19328@netspace.org>
References: <20040808002223.505ada33@parker>
 <3BD1795D-E8C2-11D8-A007-000393753936@gbiv.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3BD1795D-E8C2-11D8-A007-000393753936@gbiv.com>
User-Agent: Mutt/1.4.1i

On Sat, Aug 07, 2004 at 03:36:33PM -0700, Roy T. Fielding wrote:
> >>CGI would happen after mod_deflate.  If mod_deflate changes the 
> >>request
> >>body without also (un)setting content-length, then it is broken.
> >
> >Huh? Input filters are pulled, so they run *after* the handler has been
> >started. And - CONTENT_LENGTH (if any - It's unset for chunked as 
> >well) still
> >reflects the Content-Length sent by the client. So the current 
> >behaviour is
> >correct in all cases.
> 
> No, it is broken in all cases.  CGI scripts cannot handle chunked input
> and they cannot handle bodies without content-length -- that is how the
> interface was designed.  You would have to define a CGI+ interface to
> get some other behavior.
> 
> >A CGI script therefore should never trust Content-Length, but just read
> >stdin until it meets an EOF.
> 
> We cannot redefine CGI.  It is a legacy crap interface.  Input filters
> either have to be disabled for CGI or replaced with a buffering system
> that takes HTTP/1.1 in and supplies CGI with the correct metadata and 
> body.

Actually, IMHO, RFC 2616 Section 4.4 clearly defines expected behavior:

   For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
   containing a message-body MUST include a valid Content-Length header
   field unless the server is known to be HTTP/1.1 compliant. If a
   request contains a message-body and a Content-Length is not given,
   the server SHOULD respond with 400 (bad request) if it cannot
   determine the length of the message, or with 411 (length required) if
   it wishes to insist on receiving a valid Content-Length.

Since the Apache server can not know if CGI requires C-L, I conclude
that CGI scripts are broken if they require C-L and do not return
411 Length Required when the CGI/1.1 CONTENT_LENGTH environment
variable is not present.  It's too bad that CGI.pm and cgi-lib.pl
are both broken in this respect.  Fixing them would be simple and
that would take care of the vast majority of legacy apps.

For custom apps, supporting T-E chunked and C-L in CGI is trivial,
and only requires that the calling app use a get_input() or similar
abstraction instead of read()ing directly from stdin.

In Apache 1.3, ap_setup_client_block(r, REQUEST_CHUNKED_PASS);
just passes along chunks to target applications.  Adding support
to mod_cgi in Apache2 for passing chunks is also straightforward.

Cheers,
Glenn