You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Eric Covener <co...@gmail.com> on 2010/04/26 11:55:20 UTC
Re: svn commit: r937858 - in /httpd/httpd/trunk: CHANGES
modules/http/http_filters.c
On Mon, Apr 26, 2010 at 2:04 AM, Roy T. Fielding <fi...@gbiv.com> wrote:
> I am confused. Why is this a good idea? Why is it unexpected to
> encounter a 413 response after a timeout due to a read of chunked
> body,
The body is not too large, and the server is not rejecting the body
due to size. Isn't 413 a very misleading status?
> and how does changing it to a 400 somehow prevent a double
> errordoc? Why not just fix the double errordoc bug instead of
> the case that triggers it?
This was the secondary part to me, but I'll open a bug with an example
(IIUC, filter that adds an error bucket but then also returns a
(non-http) error).
--
Eric Covener
covener@gmail.com
Re: svn commit: r937858 - in /httpd/httpd/trunk: CHANGES
modules/http/http_filters.c
Posted by Eric Covener <co...@gmail.com>.
On Mon, Apr 26, 2010 at 6:15 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
> On Apr 26, 2010, at 2:55 AM, Eric Covener wrote:
>
>> On Mon, Apr 26, 2010 at 2:04 AM, Roy T. Fielding <fi...@gbiv.com> wrote:
>>> I am confused. Why is this a good idea? Why is it unexpected to
>>> encounter a 413 response after a timeout due to a read of chunked
>>> body,
>>
>> The body is not too large, and the server is not rejecting the body
>> due to size. Isn't 413 a very misleading status?
>
> Er, yeah, 413 is wrong -- I should have looked it up. It should be
> a 408 (Request Timeout).
400->408 in r938265.
--
Eric Covener
covener@gmail.com
Re: svn commit: r937858 - in /httpd/httpd/trunk: CHANGES modules/http/http_filters.c
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Apr 26, 2010, at 2:55 AM, Eric Covener wrote:
> On Mon, Apr 26, 2010 at 2:04 AM, Roy T. Fielding <fi...@gbiv.com> wrote:
>> I am confused. Why is this a good idea? Why is it unexpected to
>> encounter a 413 response after a timeout due to a read of chunked
>> body,
>
> The body is not too large, and the server is not rejecting the body
> due to size. Isn't 413 a very misleading status?
Er, yeah, 413 is wrong -- I should have looked it up. It should be
a 408 (Request Timeout).
>> and how does changing it to a 400 somehow prevent a double
>> errordoc? Why not just fix the double errordoc bug instead of
>> the case that triggers it?
>
> This was the secondary part to me, but I'll open a bug with an example
> (IIUC, filter that adds an error bucket but then also returns a
> (non-http) error).
Well, if it is fixed as Ruediger explained, then I am fine with it.
I just couldn't see the fix in that patch.
....Roy