Re: Resend: Re: IPP> Chunked POST: SUMMARY

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?

     -Carl



http-wg@hplb.hpl.hp.com on 01/22/99 02:52:23 PM

To:   "Hastings, Tom N" <hastings@cp10.es.xerox.com>
cc:   Carl Kugler/Boulder/IBM, http-wg@cuckoo.hpl.hp.com, ipp@pwg.org
Subject:  Re: Resend: Re: IPP> Chunked POST: SUMMARY





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 18:01:46 UTC