You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Bill Stoddard <bi...@wstoddard.com> on 2002/04/25 22:39:18 UTC
REQUEST_CHUNKED_DECHUNK question
>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?
Being overly pedantic... setup_client_block() does not take a buffer as an argument so the
comment is non-sequiter. I assume this comment applies to the caller of
ap_get_client_block() in which case.... it seems that a client sending chunked data in a
POST could send arbitarily large chunks, so how is the caller to ap_get_client_block to
ever know how large a buffer to pass in?
Bill
Re: REQUEST_CHUNKED_DECHUNK question
Posted by Bill Stoddard <bi...@wstoddard.com>.
> 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.
I didn't know what "chunk-size line" was. Now that I know what it means, the comment makes
perfect sense. Definitely an edge case. Thanks for explaining.
Bill
Re: REQUEST_CHUNKED_DECHUNK question
Posted by "Roy T. Fielding" <fi...@apache.org>.
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
Re: REQUEST_CHUNKED_DECHUNK question
Posted by Justin Erenkrantz <je...@apache.org>.
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?
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