On Fri, 22 Jan 1999 kugler at us.ibm.com wrote:
>>> Roy, would implementing it as a Java servlet be braindead? Should every
> application that uses HTTP as a transport build in its own HTTP
> implementation, even if one is already available on the platform? Even in
> the future?
>
This discussion is getting off track. There is a problem here and it
may well impinge on IPP. But the problem is not with the HTTP spec.
The problem is that there is no way to use CGI with chunked message-bodies.
This is can be viewed as a limitation of CGI (CGI's problem) or a
limitation of the most popular implementations of HTTP (HTTP implementor's
problem). But it is not a problem with the HTT Protocol. HTTP does
not prevent using chunking with CGI and it is not hard to find servers
which support this, even though the most popular ones do not.
You might also blame the CGI protocol for not permitting the use of
chunked input. This could only be changed in a new version of CGI.
It is not very helpful to tell people what they want to do is braindead.
Obviously, some uses of CGI are useful and appropriate and some are not.
Also this really has nothing to do with denial of service which can be
done in lots of ways more easily than using chunking.
I am not sure what recourse people have at this point. You could try
to persuade Apache developers to implement this feature. I am not
sure if it would be possible to write an Apache module to do this.
You could also try to support a new version of the CGI spec which would
permit CGI to take chunked input. Neither of these would deal with the
existing base of installed servers, though.
But the one thing which does seem clear is that no change or
clarification in the HTTP spec can can help.
In that regard, I would suggest that a server which rejects chunked
message-body but returns a 200 status is not in compliance with the
spec as it stands now.
John Franks
john at math.nwu.edu