On Thursday, April 25, 2002, at 03:27 PM, Justin Erenkrantz wrote:
> On Thu, Apr 25, 2002 at 04:39:18PM -0400, Bill Stoddard wrote: >>> From http_protocol.c... >> >> * 1. Call setup_client_block() near the beginning of the request >> * handler. This will set up all the necessary properties, and will >> * return either OK, or an error code. If the latter, the module >> should >> * return that error code. The second parameter selects the policy to >> * apply if the request message indicates a body, and how a chunked >> * transfer-coding should be interpreted. Choose one of >> * >> * REQUEST_NO_BODY Send 413 error if message has any body >> * REQUEST_CHUNKED_ERROR Send 411 error if body without >> Content-Length >> * REQUEST_CHUNKED_DECHUNK If chunked, remove the chunks for me. >> * >> * In order to use the last two options, the caller MUST provide a >> buffer >> * large enough to hold a chunk-size line, including any extensions. >> * >> >> Anyone know off the top of their head know what the last sentence really >> means? In 1.3 and >> 2.0? > It means that the buffer passed for the later get_client_block calls must be large enough to handle the chunk-size integer in character form, since the parser will fail if it has to stop in mid-read of the integer (not mid-read of the data within the chunk). I don't know if it still applies to 2.0. > FWIW, all of this code is essentially a no-op in 2.0 now since the > filters handle the chunking transparently. Right now, there is no > way to get the chunks without bypassing the filters. I assume we > could either setup a flag or the module needs to explicitly remove > HTTP_IN. (Indeed, I believe that removing the HTTP_IN filter is > the best way to go if you want the real body.) -- justin Harrumph. I hate it when features disappear. The right solution is for the HTTP_IN filter to obey that parameter, not ignore it. ....Roy
