- From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
- Date: Fri, 22 Jan 1999 13:45:00 -0800
- To: "Hastings, Tom N" <hastings@cp10.es.xerox.com>
- Cc: kugler@us.ibm.com, http-wg@cuckoo.hpl.hp.com, ipp@pwg.org
An IPP server is not going to be a general-purpose HTTP server, and implementing it as a CGI script would be braindead anyway, so why does the fact that a general-purpose HTTP server reject some non-length-given POST requests matter to IPP? In other words, if you are already assuming that the destination server can handle an IPP message, why can't you assume that it can also handle chunked input? The fact that it isn't required by HTTP in general doesn't mean you can't require it for particular resources. Or even for any IPP gateway. Apache, for instance, includes the ability to parse and forward chunked input within the core server -- it is only the mod_cgi module that won't accept it. The denial of service case exists for any service. Basically, the service needs some mechanism of rejecting a request and giving a reason for that rejection, preferably providing a means for the client to workaround the limitation if it is legitimate. The 411 and 413 response codes describe two such reasons. ....Roy
Received on Friday, 22 January 1999 13:57:19 UTC