W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1999

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

From: <kugler@us.ibm.com>
Date: Fri, 22 Jan 1999 18:53:14 -0700
To: http-wg@hplb.hpl.hp.com
Cc: "Hastings, Tom N" <hastings@cp10.es.xerox.com>, http-wg@cuckoo.hpl.hp.com, ipp@pwg.org
Message-Id: <87256702.000A9CFF.00@d53mta08h.boulder.ibm.com>

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?


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.

Received on Saturday, 23 January 1999 01:58:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:33 UTC